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ABSTRACT 


A  least  privilege  separation  kernel  (LPSK)  is  part  of  a  long-term  project  known  as 
the  Trusted  Computing  Exemplar  (TCX).  A  major  objective  of  the  TCX  is  the  creation 
of  an  open  framework  for  high  assurance  development.  A  relatively  new  specification 
tool  called  Alloy  has  shown  potential  for  high  assurance  development.  We  implemented 
the  formal  security  policy  model  (FSPM)  and  the  formal  top  level  specification  (FTLS) 
of  the  TCX  LPSK  in  Alloy  and  concluded  that  Alloy  has  few  limitations  and  is  more  than 
sufficiently  useful,  as  measured  by  utility  and  ease  of  use,  to  include  in  the  TCX 
framework. 
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EXECUTIVE  SUMMARY 


A  least  privilege  model  for  separation  kernels  (LPSK)  is  an  example  of  a  high 
assurance  software  system  and  a  key  component  of  a  long  term  development  project  of 
the  CISR  group  at  the  Naval  Postgraduate  School  (NPS)  known  as  the  Trusted 
Computing  Exemplar  (TCX).  An  overarching  goal  of  the  TCX  project  is  the 
establishment  of  an  open  framework  for  rapid  high  assurance  development  [Irv04] .  High 
assurance  systems  are  developed  using  a  rigorous  mathematical  approach  known  as 
formal  methods. 

Former  NPS  students  explored  fonnal  specification  tools  such  as  PVS  [Ubh03] 
and  Specware  [Dec06]  for  their  usefulness  in  formally  verifying  the  Bell  and  LaPadula 
model  and  the  TCX  LPSK,  respectively.  These  tools  lack  the  ability  to  clearly  specify 
state  model  semantics.  The  TCX  framework  aims  to  not  only  identify  a  high  assurance 
toolset,  but  a  toolset  of  standalone  tools  with  ease  of  use  and  low  learning  curves.  The 
successful  dissemination  and  adoption  of  the  framework  by  the  growing  high  assurance 
development  community  will  depend  on  not  only  the  utility  of  the  framework’s  toolset, 
but  also  in  the  ease  of  use  of  the  toolset. 

Alloy  is  a  new  form  of  model  building  based  on  the  small  scope  hypothesis 
[Jac06].  The  hypothesis  states  that  if  an  inconsistency  in  a  model  exists  there  is  a  high 
probability  that  it  will  present  itself  within  a  small  scope  of  the  model.  The  ability  to  get 
feedback  from  the  Alloy  Analyzer  in  the  form  of  model  instances  and  counterexamples 
makes  this  tool  distinct  from  older  formal  specification  techniques.  We  set  out  to 
investigate  if  a  relative  novice  to  high  assurance  development  in  an  “apprentice”  like  role 
can  use  Alloy  to  adequately  describe  the  formal  security  policy  model  (FSPM)  and  the 
formal  top  level  specification  (FTLS)  of  a  system  like  the  TCX  LPSK,  prove  their 
consistency,  and  demonstrate  property  preservation  between  their  mappings. 

Two  documents  exist  for  the  TCX  LPSK.  One  states  the  security  policy  of  the 
TCX  LPSK  [Lev04]  and  the  other  describes  the  preliminary  interface.  The  security 
policy  document  contains  both  the  security  policy  and  a  FSPM  written  in  predicate  logic. 
The  preliminary  interface  document  contains  a  description  of  high  level  function  names 
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with  corresponding  parameters  and  return  values.  We  first  produced  an  Alloy 
specification  that  matches  the  behavior  stated  in  the  security  policy  document. 

The  security  policy  consists  of  two  predicates,  one  to  restrict  information  flow 
and  one  ( TPO )  to  restrict  extraordinary  flows,  to  trusted  subjects  (those  that  go  beyond 
the  identified  partial  ordering).  We  defined  and  tested  the  information  flow  predicate 
without  complication.  This  was  not  the  case  for  the  trusted  partial  ordering  predicate 
TPO.  During  testing  the  Alloy  Analyzer  produced  models  that  did  not  conform  to  the 
trusted  partial  ordering.  We  ultimately  detennined  the  reason  for  the  inconsistency  was 
not  a  weakness  of  the  Alloy  specification  language  or  of  the  security  policy,  but  our 
particular  expression  of  the  intended  security  policy.  Understanding  this  we  constructed 
an  alternative  specification  of  the  TPO  which  more  clearly  describes  the  intended  security 
policy.  This  was  a  major  success  of  our  experimentation. 

We  then  augmented  the  FSPM  specification  to  create  an  FTLS.  We  did  this  by 
adding  a  predicate  representing  each  class  of  interface  in  the  preliminary  LPSK  interface 
document.  Our  models  were  helpful  in  demonstrating  how  the  security  properties  hold 
between  the  security  policy  and  the  preliminary  interface.  Being  that  the  interface  is  still 
in  a  preliminary  stage  our  work  was  additionally  useful  to  the  designers  in  furthering  its 
development. 

We  demonstrate  that  Alloy  is  an  important  tool  to  include  in  the  toolbox  of  rapid 
high  assurance  development.  Its  low  learning  curve  allows  for  the  beginner  to  formal 
methods  and  high  assurance  systems  to  quickly  hone  their  development  skills.  We  also 
demonstrate  that  Alloy  is  useful  even  for  more  seasoned  developers. 
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I.  INTRODUCTION 


A  least  privilege  model  for  separation  kernels  (LPSK)  is  an  example  of  a  high 
assurance  software  system  and  a  key  component  of  a  long  term  development  project  of 
the  CISR  group  at  the  Naval  Postgraduate  School  (NPS)  known  as  the  Trusted 
Computing  Exemplar  (TCX).  An  overarching  goal  of  the  TCX  project  is  the 
establishment  of  an  open  framework  for  rapid  high  assurance  development  [Irv04] .  High 
assurance  systems  are  developed  using  a  rigorous  approach  known  as  formal  verification, 
which  requires  the  use  of  mathematical,  formal  methods. 

Formal  methods  tools,  such  as  theorem  provers  and  model  checkers,  help 
construct  specifications  for  hardware  and  software  and  mathematically  verify  their 
correctness.  Fonner  NPS  students  explored  formal  specification  tools  such  as  PVS 
[Ubh03]  and  Specware  [Dec06]  for  their  usefulness  in  formally  verifying  security 
policies  such  as  those  in  the  TCX  FPSK.  These  tools  lack  the  ability  to  clearly  specify 
state  model  semantics.  Also,  tool  complexities  prevented  the  students  from  fully 
implementing  security  policy  models  for  the  TCX  FPSK. 

The  Alloy  specification  language  provides  a  simple  and  clear  language  which 
should  allow  for  modeling  the  TCX  FPSK  in  its  entirety.  Work  done  by  Jackson  and 
others  [JacOl,  Has04]  demonstrates  Alloy’s  usefulness  in  memory  protection  and  MFS 
models.  Therefore,  we  set  out  to  investigate  if  a  relative  novice  to  high  assurance 
development  in  an  apprentice-like  role  can  use  Alloy  to  adequately  describe  the  formal 
security  policy  model  (FSPM)  and  the  formal  top  level  specification  (FTFS)  models  of  an 
FPSK,  prove  their  consistency,  and  the  validity  of  the  FSPM-FTFS  mapping. 

We  present  a  basic  overview  of  Alloy.  Then  we  present  our  Alloy  versions  of  the 
FSPM  and  the  FTFS  for  an  FPSK.  Base  on  our  experiences  in  developing  the  FSPM  and 
the  FTFS,  we  analyze  the  usefulness  and  limitations  of  Alloy  in  security  system 
specification  and  proof.  In  this  analysis  we  use  the  formal  methods  tool  evaluation 
criteria  developed  by  Ubhayakar  and  adapted  by  DeCloss.  In  addition  to  specifying  the 
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model  in  Alloy,  we  extended  the  fonnal  specification  of  the  TCX  LPSK  to  include  initial 
conditions  and  runtime  state  changes.  The  current  developers  of  the  TCX  LPSK  found 
this  very  useful. 
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II.  BACKGROUND 


A.  FORMAL  METHODS 

The  current  industrial  paradigm  of  software  security  involves  constant  patching  of 
reused  software.  This  paradigm  is  untenable.  Security  and  safety  critical  software 
require  an  extremely  high  degree  of  assurance  that  they  will  behave  as  expected.  Lives 
depend  on  the  proper  functioning  of  medical  and  aviation  software.  Lives  depend  on  the 
proper  containment  of  state  secrets  held  on  infonnation  systems.  The  confidentiality  of 
large  amounts  of  high  value  information  (both  personal  and  financial)  in  commercial- 
industrial  databases  needs  better,  high  assurance  protection.  Formal  methods  are  the 
preferred  solution  to  the  development  of  high  assurance  software. 

The  formal  methods  process  rigorously  verifies  successive  layers  of  software 
development  in  order  to  ensure  that  the  system  implementation  enforces  the  security 
policy.  At  the  top  layer,  a  policy  is  conceived  and  then  the  policy  is  described  in  terms  of 
a  Formal  Security  Policy  Model  (FSPM).  From  there  a  Formal  Top  Level  Specification 
(FTLS)  is  constructed,  and  then  the  final  implementation  [Bow03]. 


Policy  <-  FSPM  <-  FTLS  <-  Implementation 
Figure  1.  Formal  Methods  Mappings 

The  backward  arrows  in  Figure  1  are  used  to  indicate  a  mapping  to  the 
predecessor  layer.  This  mapping  usually  involves  rigorous  assurance  such  as  that 
provided  by  category  theoretic  morphisms.  The  effort  of  formal  verification  is  eased  if 
the  specification  language  includes  linguistic  elements  for  describing  the  mapping 
between  different  levels  of  abstraction  and  can  automatically  generate  theorems  regarding 
the  correctness  of  the  mappings.  However,  the  reader  will  notice  that  this  is  not  possible 
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between  the  Policy  and  FSPM  layers,  because  the  FSPM  is  intended  to  reflect  the 
Policy’s  English  description.  Consequently,  assurance  that  the  FSPM  accurately  reflects 
the  Policy  is  accomplished  by  peer  review. 

Formal  specification  languages  and  related  theorem  provers,  such  as  PVS,  are 
common  tools  used  in  high  assurance  software  development.  Theorem  provers  are  time 
consuming,  costly,  and  limited  in  their  ability  to  be  fully  automated.  The  assistance  they 
require  from  a  human  operator  is  nontrivial.  Model  checkers,  such  as  SPIN,  use  temporal 
logic  to  model  the  consistency  of  finite  state  machines  in  an  automated  fashion.  Most 
software  programs  of  any  importance  tend  to  be  infinite  state  systems  with  properties  that 
are  computationally  undecidable.  Therefore,  the  success  of  model  checkers  has  been 
mostly  limited  to  hardware  and  they  have  not  been  well  suited  for  the  complexity  of 
software.  Current  academic  thought  is  that  secure  software  requires  a  combination  of 
formal  languages  and  automated  correctness  proofs  for  correct  development. 

Alloy  is  a  fonnal  tool  set  that  includes  a  specification  language  and  a  model 
analyzer.  Alloy  does  not  provide  built-in  syntactical  elements  for  morphisms.  However, 
it  is  well  suited  for  incremental  development.  In  our  experimentation  our  init  and 
runtime  models  correspond  to  the  FTLS  and  are  augmentations  of  the  security  model 
which  corresponds  to  the  FSPM.  In  the  future  work  section  we  included  a  recommend 
approach  for  adding  inter  level  mapping  to  Alloy  models. 

B.  THE  TCX 

Over  the  years  the  computer  security  community  has  created  many  standards  and 
documents  detailing  and  outlining  principles  of  computer  security.  Examples  include  the 
Trusted  Computer  System  Evaluation  Criteria  (TCSEC),  also  known  as  the  Orange  Book, 
and  the  Federal  Information  Processing  Standards  (FIPS).  The  Common  Criteria  is  an 
international  standard  that  has  attempted  to  build  a  unifying  standard  for  the  underlining 
requirements  of  a  secure  computer  system.  A  computer  system  evaluated  under  the 
Common  Criteria  will  receive  an  Evaluation  Assurance  Level  (EAL)  from  1  to  7,  7  being 
the  best  [Com05].  Formal  methods  are  an  integral  part  of  the  development  of 


4 


EAL7  systems.  The  few  commercial  products  which  provide  high  assurance  according  to 
Common  Criteria  standards  use  proprietary  methods,  management,  and  code  not  open  to 
the  public. 

The  Trusted  Computing  Exemplar  (TCX)  is  a  project  to  develop  an  EAL7  system 
that  is  open  to  the  public  in  the  spirit  of  the  open  source  movement.  The  TCX  includes  a 
formal  specification  of  a  least  privilege  separation  kernel  (LPSK)  which  will  provide  an 
open  framework  that  other  academic,  commercial,  and  military  institutions  can 
corroborate  and  build  on  to  provide  high  assurance  software  to  the  Navy,  Department  of 
Defense,  and  the  national  information  infrastructure.  The  TCX  framework  aims  to 
identify  a  set  of  interoperable  standalone  tools  that  feature  ease  of  use  and  low  learning 
curves  [Irv04],  The  successful  dissemination  and  adoption  of  the  framework  by  the 
growing  high  assurance  development  community  will  depend  on  not  only  the  utility  of 
the  framework’s  toolset,  but  also  in  the  ease  of  use  of  the  toolset. 

C.  LPSK 

The  concept  of  a  separation  kernel  was  first  proposed  by  Rushby  in  1981[Rus81]. 
In  recent  years  separation  kernels  have  gained  in  popularity  and  are  currently  used  in 
military  avionics,  military  communications,  and  virtual  machine  monitors  (VMM).  A 
separation  kernel  partitions  the  system  resources  and  controls  the  flow  of  information 
between  the  partitions.  The  separation  kernel  ensures  that  no  information  flows  between 
partitions  contrary  to  a  set  of  allowed  flows. 

A  separation  kernel  that  allocates  resources  to  partitions  and  processes  in  a  fixed 
manner  upon  initialization  is  called  a  static  separation  kernel.  For  example,  the  kernel 
allots  a  fixed  amount  of  processing  time  to  each  of  its  partitions.  Dynamic  time  slices 
allow  for  the  possibility  of  insecurities  know  as  covert  channels  [Mil89].  Covert  channel 
analysis  can  be  very  complex.  Therefore,  static  separation  kernels  are  desirable  for 
simplicity  of  design,  although  at  the  expense  of  flexibility  and  efficiency  of  the  system. 
The  Principle  of  Least  Privilege  [Sal75]  requires  active  resources  in  a  system  to  not  have 
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more  privileges  than  is  absolutely  necessary.  Therefore  a  least  privilege  separation 
kernel  (LPSK)  is  a  separation  kernel  that  also  implements  the  Principle  of  Least 
Privilege. 

In  October  2004,  the  CISR  group  at  the  Naval  Postgraduate  School  published  A 
Least  Privilege  Model  for  Static  Separation  Kernels  [Lev04].  It  is  a  high-level  design 
document  for  a  LPSK  and  its  security  policy.  The  document  contains  both  a  description 
of  the  security  policy  and  a  FSPM  written  in  predicate  logic  that  specifies  the  critical 
elements  of  a  LPSK,  and  a  security  predicate  over  all  possible  operations  that  could  be 
included  in  a  secure  system.  The  initial  and  runtime  conditions  were  not  included  in  this 
model,  but  are  operations  contributed  by  our  experimentation.  The  CISR  group  is 
currently  in  the  process  of  producing  an  interface  description  for  the  TCX  LPSK.  This 
preliminary  interface  document  describes  the  TCX  LPSK’s  high  level  function  names 
and  corresponding  parameters  and  return  values.  This  provided  the  input  for  our  FTLS  of 
the  TCX  LPSK.  Since  the  interface  document  was  still  in  draft  form,  we  worked  with  the 
authors  to  both  ensure  our  understanding  of  the  interface  as  well  as  to  help  ensure  the 
consistency  of  the  interface  document. 
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III.  OVERVIEW  OF  ALLOY 


A.  ALLOY’S  INNOVATION 

1.  The  Small  Scope  Hypothesis 

Theorem  provers  are  used  to  prove  the  properties  of  a  specification  (e.g.,  the 
policies  of  a  system)  with  certainty.  However,  provers  are  complex  tools,  not  fully 
automated,  and  very  time  consuming.  Traditional  model  checkers  have  not  been  well 
suited  for  the  complexity  of  software.  However,  the  Alloy  Analyzer  is  a  new  form  of 
model  building  based  on  the  “small  scope  hypothesis”  that  builds  models  from  a  semantic 
language  of  sets  and  first  order  predicate  logic  similar  to  Z. 

The  small  scope  hypothesis  forms  the  basis  for  the  use  of  model  builders  in 
contexts  that  require  assurance  of  correctness.  It  states  that  if  an  inconsistency  in  a  model 
exists  there  is  a  high  probability  that  it  will  present  itself  within  a  small  scope  of  the 
model  [Jac06].  For  example,  in  a  model  of  a  file  system  the  number  of  files  modeled  is 
the  “scope.”  If  no  error  or  inconsistency  is  found  by  the  model  analyzer  in  a  model  of  ten 
files,  there  is  a  very  low  probability  that  an  error  or  inconsistency  will  present  itself  in  a 
much  larger  model  of  a  hundred  files.  This  small  scope  hypothesis  allows  for  the  rapid 
verification  of  software  specifications  with  much  greater  detail  than  other  tools. 

The  small  scope  hypothesis  is  not  without  its  skeptics.  Formal  methods  in  the 
strictest  sense  demand  a  certainty  of  correctness  and  do  not  allow  for  a  probability  of 
correctness.  The  Common  Criteria’s  highest  level  of  security  is  EAL7.  If  a  product 
obtains  this  level  of  evaluation  it  can  be  said  that  it  was  developed  with  tools  that  have 
sufficiently  proven  security.  Nevertheless,  in  2002,  Clark  Wiesman  used  Alloy  to 
develop  a  specification  of  an  assurance  system  with  the  goal  of  EAL7  evaluation 
[Wie02].  The  Common  Criteria  only  requires  that  formal  tools  be  used  in  development, 
but  makes  no  mention  of  the  specific  tools  to  be  used,  be  they  model  checkers,  theorem 
provers,  or  otherwise.  “Where  the  functional  specification  is  formal,  the  proof  of 
correspondence  between  the  TSP  model  and  the  functional  specification  shall  be  formal.” 
[Com05] 
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2. 


Immediate  Visualization 


Alloy  connects  the  elegant  world  of  specification  languages  with  the  power  of  the 
world  of  model  checkers.  Two  great  positive  aspects  of  Alloy  are  the  ease  with  which 
the  user  can  express  their  model  and  the  readiness  with  which  the  user  can  see  if  they 
have  expressed  what  they  intended.  In  essence,  Alloy  has  automated  a  process  that 
occurs  with  peer  review.  Alloy  predecessors,  such  as  Z,  do  not  have  this  advantage. 
They  require  a  large  amount  of  effort  to  properly  verify  a  model.  Then  more  effort  is 
required  to  verily  with  peers  if  the  specification  indeed  models  what  is  desired. 

The  Alloy  tool  set  consists  of  the  Alloy  Analyzer  and  the  Alloy  specification 
language.  The  Alloy  specification  language  has  evolved  from  Z  notation.  The  syntax 
defines  sets  and  relations  in  such  a  way  that  it  almost  appears  to  be  an  object  oriented 
programming  language.  The  elegance  and  simplicity  of  this  syntax  allows  for  a  large 
amount  of  natural  expressivity.  The  Alloy  Analyzer  reads  an  Alloy  specification,  checks 
its  syntax,  and  searches  for  specification  inconsistencies  within  the  defined  scope.  If  the 
analyzer  finishes,  its  list  of  inconsistencies,  if  any  are  present,  is  ensured  to  be  complete. 
It  then  produces  models  that  can  be  viewed  as  box  or  tree  structured  graphs.  This 
provides  immediate  feedback  that  the  user  can  use  to  understand  what  it  is  they  have 
modeled. 

The  Alloy  Analyzer  first  verifies  the  Alloy  specification  syntax  and  then  converts 
it  into  a  propositional  logic  formula  -  a  normalized  Boolean  expression.  The  Alloy 
Analyzer  then  feeds  the  propositional  formula  into  a  third  party  satisfiability  (SAT) 
solver  which  is  used  to  generate  either  counter  examples  or  models  that  can  be 
immediately  visualized.  The  ability  to  get  feedback  from  the  Alloy  Analyzer  in  the  form 
of  model  instances  and  counterexamples  makes  this  tool  distinct  from  older  fonnal 
specification  techniques. 

Figure  2  shows  a  simple  Alloy  specification  of  system  containing  an  access 
matrix.  Figure  3  shows  a  graph  visualization  of  a  model  that  confonns  to  the  constraints 
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of  the  Figure  2  specification.  One  thing  that  we  see  immediately  is  multiple  “systems”  in 
the  model.  This  is  because  the  specification  did  not  specify  only  one  system  should  exist. 


sig  Resource  { } 

sig  Matrix 

{ 

subj  ect  s 

set  Resource, 

ob j ects  : 

set  Resource, 

access : 

i 

sub j  ects->obj  ects 

sig  System 

{ 

progr  am : 

Resource- >Re source. 

matrix: 

} 

Matrix 

pred  show 
run  show 

0  u 

Figure  2.  A  Simple  Alloy  Specification 


Figure  3.  Visualization  Corresponding  to  Simple  Alloy  Specification 
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3. 


SAT  Solvers 


The  Boolean  satisfiability  problem  consists  of  assigning  values  to  a  nonnalized 
Boolean  expression  (and’s  and  or’s  only)  such  that  it  results  in  a  true  expression.  In 
complexity  theory  the  problem  is  considered  non-deterministic  polynomial  time  complete 
(NP-complete).  This  means  that  a  fool-proof  fast  solution  to  the  problem  is  unlikely  to 
ever  be  found.  However,  SAT  solvers  use  heuristics  such  as  pruning  to  quickly  find 
solutions  in  a  search  space  (i.e.,  within  the  defined  scope).  Many  good  SAT  solvers  are 
freely  available  and  new  improved  SAT  solvers  are  frequently  released. 

There  may  be  many  assignments  of  values  that  result  in  a  true  expression. 
Therefore,  there  may  be  multiple  solutions.  If  no  such  assignment  is  possible  within  the 
defined  scope  then  there  is  no  solution.  The  Alloy  Analyzer  offers  a  variety  of  SAT 
solvers.  The  SAT4J  solver  will  produce  multiple  solutions  when  multiple  solutions  exist. 
With  the  SAT4J  solver  the  user  can  click  the  next  button  in  the  visual  display  area  to 
view  other  satisfying  models.  If  no  satisfying  model  is  found,  Alloy  will  produce  an 
error  message  that  the  model  may  be  inconsistent. 

B.  ALLOY’S  LANGUAGE 

1.  Syntax 

The  ‘sig’  keyword  (short  for  signature)  is  used  to  declare  sets.  The  declared  sets 
can  be  operated  on  much  as  if  they  were  objects  in  an  object  oriented  programming 
language.  The  ‘ extends ’  keyword  will  create  disjoint  subsets.  The  'abstract'  keyword 
indicates  that  an  item  should  not  be  created  in  the  model,  but  that  items  extended  from  it 
may.  The  'extends'  and  'abstract'  keywords  are  analogous  to  object  oriented 
programming  with  a  hierarchy  of  parent  and  child  classes.  In  Figure  4  the  'one'  keyword 
is  a  multiplicity  keyword  that  means  one  and  only  one  item  should  be  in  the  model. 


abstract  sig  Mode  { } 

one  sig  RD,  WT  extends  Mode  { } 


Figure  4.  abstract  and  extends  Keywors 
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The  ‘ pred ’  keyword  declares  a  predicate  that  returns  only  a  true  or  false  value. 
The  ‘ fun ’  keyword  is  used  for  functions  and  both  functions  and  predicates  may  take 
parameters.  The  ‘ fact'  keyword  can  be  used  anywhere  in  the  specification  to  place 
constraints  on  the  model.  The  example  in  Figure  5  would  require  at  least  one  System 
item  be  in  the  model.  That  is,  it  would  eliminate  any  model  with  an  empty  System  as  a 
model  that  satisfies  the  specification.  The  ‘ assert ’  keyword  is  use  to  verify  that  certain 
conditions  hold  in  the  specification.  The  example  in  Figure  6  would  verify  that  every 
System  in  the  model  conforms  to  the  Secure  predicate.  If  this  is  not  the  case  the  Alloy 
Analyzer  would  produce  a  counter  example. 


fact.  {  some  System  } 


Figure  5.  Example  of  a  Specification  Constraint 


assert  Security Ho Ids  ■{  all  sys:  System  |  Secure  [sys]  } 
check  SecurityHolds 


Figure  6.  Example  of  Model  Assertion 


2.  A  Mix  of  Relational  and  Predicate  Logic 

Alloy  uses  an  elegant  mix  of  relational  logic  and  first  order  predicate  logic.  It  is 
not  higher  ordered.  This  means  that  quantification  can  not  directly  occur  over  functions, 
relations,  or  predicates.  However,  this  doesn’t  appear  to  be  problematic  and  there  is 
almost  always  a  way  to  restate  such  a  problem.  (See  page  41  of  Software  Abstractions) 
This  did  take  some  time  to  become  accustomed  to.  The  specification  in  Figure  7  states 
the  obvious,  that  is,  every  possible  block  to  block  relation  is  in  the  set  of  block  to  block 
relations.  Figure  7  will  give  a  higher  order  compiler  error.  However,  we  were  able  to 
work  around  this  by  wrapping  the  relation  into  a  signature  as  shown  in  Figure  8. 
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sig  Block 

{  1 

pred  P  (  ) 

1 

all  bb: 

Block->Block  | 

bb  in 

Block- >Block. 

} 

run  P 

Figure  7.  Quantification  Over  A  Relation 


sig  Block  { } 
sig  Matrix  { 

bb :  Block->Bl ock 

} 

pred  P  (  )  { 

all  m:  Matrix  | 

m.bb  in  Block- >Block. 

> 

run  P 


Figure  8.  Relation  Wrapped  In  A  Signature 


3.  The  Join  Operation 

Most  students  will  recall  the  join  operation  from  their  set  theory  or  discrete  math 
classes.  The  join  operation  is  what  provides  most  of  the  power  and  simplicity  to  Alloy. 
With  a  brief  refresher  the  student  will  be  prepared  to  construct  models  in  Alloy.  In  a  join 
operation,  the  last  item  of  one  tuple  is  matched  the  first  item  of  another.  All  the  items 
except  the  matching  tuple  items  are  returned.  (See  page  57  of  Software  Abstractions) 
The  dot  join  operation  can  be  used  in  Alloy  to  access  members  of  a  signature,  implying 
the  relational  nature  of  the  signatures  members  with  the  signature  itself.  The  dot  join  is 
frequently  used  in  Alloy  with  a  set  and  a  relation.  This  is  done  to  find  the  members  of 
one  part  of  relation  such  as  in  Figure  9.  In  this  example  the  set  Mode  is  joined  with  the 
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relation  m  to  produce  just  the  Block->Block  part  of  the  relation  m.  Then  set  Block  is 
joined  with  the  resultant  value  to  produce  a  set  of  Blocks  from  the  relation. 


sig  Block  { } 
sig  Mode{ } 

sig  Matrix  { 

m:  Block->Block->Mod e 
blocks:  set  Block 

1 

{ 

blocks  in  (Block.  (m.Mode)  +  (m. Mode)  .  Block ) 

> 


Figure  9.  Join  Used  With  Relations  And  Sets 


4.  The  Transitive  Closure 

In  relational  logic  we  often  take  the  transitive  closure  of  a  set  with  respect  to  a 
relation  in  the  set.  Usually  the  transitive  closure  is  constructed  using  either  iteration  or 
recursion.  Neither  Alloy  nor  predicate  logic  possesses  iteration  or  recursion.  There  may 
be  specific  models  where  one  can  simulate  the  transitive  closure,  but  in  the  general  case 
the  transitive  closure  is  impossible  to  construct.  (See  page  234  of  Software  Abstractions) 
Consequently,  Alloy  has  a  built  in  operation  to  construct  the  transitive  closure.  The 
operation  is  represented  by  the  A  (carrot)  symbol.  The  operation’s  inclusion  into  to  the 
Alloy  specification  is  of  tremendous  significance.  We  use  this  at  key  points  in  our  model 
and  it  is  possible  that  our  model  may  not  have  been  possible  without  it. 

5.  Libraries 

The  Alloy  developers  have  adopted  the  design  philosophy  of  keeping  the  core 
syntax  simple  and  while  allowing  the  language  to  grow  and  be  enriched  by  robust 
libraries.  In  our  experimentation  we  used  a  standard  utility  library  for  common  functions 
and  a  library  for  constructing  orderings  and  sequences.  In  the  future  works  section  we 
propose  library  development  for  demonstrating  morphisms. 
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c. 


LESSONS  LEARNED 


The  average  student  with  knowledge  of  predicate  and  relation  logic  should  be  able 
to  pick  up  Alloy  with  minimal  effort.  However  there  are  occasional  subtleties  of 
predicate  logic  that  the  average  student  could  quickly  stumble  over.  One  such  example 
[Jac06,  p.71]  that  caused  us  some  effort  is  shown  in  Figure  10.  This  states  that  the 
Address  book  mapping  names  to  address  is  non  empty.  If  the  empty  address  book  is  not 
eliminated  from  the  model,  the  Alloy  Analyzer  will  produce  the  empty  address  book  as  a 
counter  example.  Figure  1 1  shows  how  this  example  might  look  in  predicate  logic. 


assert  nonempty  {  some  n:  Name,  a:  Address  |  a  in  n. entry  } 

Figure  10.  Example  From  Page  7 1 

function  Address  book.  (Name)  :  Address 

3  n:  Name,  a:  Address  |  Address  book (n)  =  a 

Figure  1 1 .  Example  In  Predicate  Logic 


As  with  any  new  language,  the  beginning  student  would  be  wise  to  always  ignore 
default  values  and  explicitly  state  the  desire  value.  In  particular  the  default  multiplicity 
in  Alloy  is  one.  For  example,  sig  Matrix  {  blocks:  Block  },  by  default  means  that  blocks 
contains  exactly  one  Block,  when  what  is  really  desired  is  a  set  of  blocks.  We  could  have 
saved  several  hours  by  always  stating  explicitly  one,  set,  lone,  etc,  in  this  case  sig  Matrix  { 
blocks:  set  Block  }. 

Without  a  doubt  advances  in  SAT  solvers  and  hardware  have  greatly  facilitated 
the  connection  between  specification  languages  and  model  analyzers.  While  working  on 
this  thesis  Alloy  was  upgraded  from  version  3  to  4,  with  a  noticeable  increase  in 
performance.  It  appears  that  hardware  and  heuristics  are  continuing  to  get  better  and  so 
the  future  for  Alloy  and  the  small  scope  hypothesis  is  bright. 
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IV.  SECURITY  MODEL 


A.  SECURITY  FRAMEWORK 

Butler  Lampson  was  the  first  to  propose  the  concept  of  an  access  matrix  to 
analyze  the  infonnation  interaction  of  a  system  [Lam71].  The  access  matrix  is  a 
representation  of  a  system  which  abstracts  system  resources  into  active  entities  called 
subjects  and  passive  entities  called  objects.  A  resource  is  anything  in  the  system  we  wish 
to  consider,  be  it  a  file,  a  process,  a  user,  a  program,  firmware,  etc.  The  objects  are 
usually  placed  along  the  columns  of  the  matrix  and  the  subjects  along  the  rows.  The  cells 
of  the  matrix  represent  modes  of  access,  usually  a  read,  write,  execute,  or  some 
combination  there  of.  The  matrix  can  then  be  used  to  study  the  flow  of  information  in  the 
system.  For  example,  in  Figure  12  subject  1  can  write  to  object  1  and  subject  2  can  read 
from  object  1  therefore  information  can  flow  freely  from  subject  1  to  subject  2. 


object  1 

object  2 

object  3 

object  4 

object  5 

subject  1 

W 

W 

W 

subject  2 

R 

R 

subject  3 

R 

RW 

R 

Figure  12.  Access  Matrix 


The  Bell  and  LaPadula  model  (named  for  its  authors)  is  a  confidentiality  policy. 
The  model  places  partially-ordered  security  labels  on  system  resources  [Bel73],  The 
model  allows  subjects  to  write  up  and  read  down  the  ordering,  but  prohibits  them  from 
writing  down  or  reading  up.  This  policy  increases  the  utility  of  the  system  by  allowing 
multiple  sensitivity  levels  to  operate  in  the  system,  while  at  the  same  time  protecting  the 
system  from  Trojan  programs  that  try  to  surreptitiously  downgrade  the  sensitive 
information. 

The  Principle  of  Least  Privilege  was  first  proposed  by  Saltzer  and  Schroeder 
[Sal75].  As  its  name  suggests,  it  requires  system  resources  to  only  have  access  privileges 
that  are  absolutely  necessary.  This  reduces  potential  vulnerabilities  by  eliminating 
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unnecessary  functionality.  Also,  the  elimination  of  discretionary  information  flows  eases 
the  effort  in  analyzing  information  flow.  All  high  assurance  systems  should  include  the 
Principle  of  Least  Privilege  in  their  design  to  reduce  flaws  and  accidental  error.  Applied 
to  the  Bell  and  LaPadula  model,  the  Principle  of  Least  Privilege  could  prohibit  a  low 
resource  from  writing  up  if  the  low  resource  has  no  compelling  reason  (e.g.,  per  the 
design)  to  do  so. 

A  separation  kernel  is  devoid  of  any  intrinsic  security  policy.  It  only  partitions 
and  isolates  system  resources  per  its  configuration  data  and  allows  specified  flows 
between  the  blocks  of  the  partition.  An  application  on  top  of  the  separation  kernel  can 
then  transpose  a  multilevel  security  policy  on  the  flow  of  information  between  the 
partitions  by  associating  labels  (top  secret,  secret,  etc)  on  the  individual  blocks. 
Applications  can  also  restrict  (e.g.,  transitive)  flows  to  establish  their  own  policies  as 
subsets  of  the  flows  allowed  by  the  separation  kernel.  This  allows  for  separating  the 
functionality  of  isolation  and  policy  interpretation,  reducing  the  complexity  of  analyzing 
the  kernel  and  may  make  the  task  of  evaluating  a  separation  kernel  more  manageable  than 
a  kernel  in  which  the  MLS  labels  are  embedded. 

Unfortunately,  while  separation  kernels  have  gained  in  popularity,  many  lack  the 
ability  to  enforce  the  Principle  of  Least  Privilege.  The  papers  Least  Privilege  Model  for 
Static  Separation  Kernels  [Lev04]  has  attempted  to  address  this  issue.  It  details  a  Fonnal 
Security  Policy  Model  (FSPM)  for  such  a  kernel.  In  our  experimentation  we  followed 
the  FSPM  as  outlined  in  the  paper  to  develop  an  Alloy  specification.  The  model  we 
developed  contains  two  essential  access  matrices  that  are  intended  to  be  orthogonal  to 
each  other.  One  represents  the  flow  of  information  between  partitions  in  the  kernel  and, 
as  required  by  the  “TPO”  predicate  to  be  discussed  later,  should  confonn  to  the  Bell  and 
LaPadula  model.  The  other  represents  the  Principle  of  Least  Privilege.  Once  the  kernel 
is  up  and  operational  it  will  remain  static.  This  means  that  the  flows  of  information  as 
allowed  by  the  two  matrices  will  not  change  during  runtime. 
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B.  SPECIFICATION  IN  ALLOY 

1.  Resources,  Modes,  and  Blocks 

We  produced  an  Alloy  specification  that  matches  the  FSPM  as  stated  in  section  5 
of  the  paper,  A  Least  Privilege  Model  for  Static  Separation  Kernels  [Lev04].  The  Alloy 
specification  language  is  well  suited  for  a  gradual,  incremental  development  style.  This 
allowed  us  a  quick  start  at  specifying  the  basic  elements  of  the  TCX  LPSK.  Once  we 
defined  resources,  subjects,  access  modes,  and  blocks  we  used  the  Alloy  Analyzer  to 
visualize  numerous  representative  models.  Initially  the  Alloy  Analyzer  produced  trivial 
and  simplistic  representative  models.  However,  without  much  difficulty  we  added  minor 
constraints  in  order  to  view  more  interesting  models. 

We  used  identifiers  similar  to  those  in  the  paper.  We  used  the  Operation 
construct  in  our  initial  experimentation  and  included  it  in  our  definition  of  the  Secure 
predicate.  However,  we  noticed  that  it  added  little  to  the  description  of  the  model.  In 
order  to  understand  other  aspects  of  the  model  we  simplified  the  model  by  removing  the 
Operation  construct  entirely.  For  this  reason  it  is  absent  in  our  final  model. 

The  word  subject  and  object  are  typically  used  to  indicate  which  resource  is  the 
active  entity  performing  the  read  and/or  write  on  another  passive  resource.  In  our  model 
we  use  the  subject  terminology  and  we  allow  one  Subject  to  operate  on  another  subject 
(i.e.,.  one  process  communicating  to  another  process).  We  drop  the  object  nomenclature 
and  simply  refer  to  a  subject  accessing  a  resource  (which  may  be  another  Subject). 

In  the  specification  every  Resource  element  is  assigned  exactly  one  and  only  one 
Block  element.  Thus  the  Block  elements  partition  the  Resource  elements  into 
equivalence  classes  as  is  intended.  The  separation  kernel  is  static,  therefore  there  is  no 
reassigning  of  Resource  elements  to  a  different  Block  once  the  kernel  is  running  and  it 
will  not  make  sense  to  have  an  empty  Block.  The  Figure  13  achieves  this  constraint. 
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sig  Block 

{  1 

{ 

s  ome  r : 

Resource 

|  r. master  =  this 

1 

Figure  13.  No  Empty  Blocks 


Of  course  we  are  only  interested  in  resources  and  blocks  that  are  inside  of  our 
System.  Because  all  Resource  elements  belong  to  a  Block,  Alloy  will  not  produce 
Resource  elements  or  Block  elements  that  have  nothing  to  do  with  each  other.  In  like 
manner  we  need  to  instruct  Alloy  that  every  Block  participates  in  the  System  to  prevent 
Alloy  from  producing  models  with  Resource  elements  and  Block  elements  that  are 
outside  of  the  System.  In  the  System  signature  we  add  this  constraint  as  seen  in  Figure 
14. 


Block  in  (  Block .( (bb . flow)  .Mode)  +  (  (bb . flow)  . Mode)  . Block  ) 


Figure  14.  All  Blocks  In  The  Relation 


2.  MM,  SR,  and  BB 


Resource  ->  Resource  — >  Mode 

Figure  15.  Access  Matrix  In  Alloy 

In  Alloy,  a  3 -tuple  or  3  item  relation  can  be  used  to  indicate  an  access  matrix  or 
set  of  flows  as  in  Figure  15.  Our  model  of  the  system  will  contain  two  access  matrices. 
One  represents  the  flow  of  information  between  blocks  (BB)  and  the  other  the  flow  of 
information  between  resources  (SR).  The  two  matrices  are  intended  to  be  orthogonal, 
that  is,  there  may  be  flows  allowed  in  one  that  are  not  allowed  in  the  other.  These 
matrices  only  determine  what  flows  are  allowed.  The  MM  matrix  represents  the  flows 
that  are  actually  realized  by  the  system  in  operation.  MM  should  be  orthogonal  to  SR 
and  BB.  That  is  SR/BB  is  the  policy  of  what  is  allowed,  and  MM  is  what  the  program 
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wants  to  do.  A  secure  system  is  a  system  in  which  all  flows  in  MM  are  allowed  by  both 
access  matrices  BB  and  SR.  Conversely,  an  insecure  system  is  a  system  that  contains  at 
least  one  flow  in  MM  not  allowed  by  both  BB  and  SR.  The  security  predicate  states  that 
a  secure  system  allows  only  the  program  actions  (MM)  that  conform  to  the  policy 
(SR/BB). 

A  Block  element  may  contain  any  combination  of  Subject  elements  and  Resource 
elements.  Therefore,  the  Block  nomenclature  is  devoid  of  the  Subject  and  Resource 
distinction.  In  order  to  better  visualize  and  talk  about  the  flow  of  information  only 
Subjects  are  allowed  to  read  and/or  write.  That  is,  Resource  elements  that  are  not  also 
Subject  elements  should  never  initiate  a  flow.  Therefore,  our  SR  is  the  relation  Subject- 
>Resource->Mode.  Technically  SR  is  not  required  to  be  a  subset  of  BB.  That  is,  it  may 
allow  flows  that  are  prohibited  by  BB,  however,  in  a  secure  system  those  flows  would 
never  be  realized,  because  what  is  allowed  is  only  the  intersection  of  the  two  matrices. 

In  the  system  signature  of  our  Alloy  specification,  MM  and  sr  flow  represent 
MM  and  SR  respectively.  However,  we  will  be  interested  in  taking  the  partial  ordering 
and  the  trusted  partial  ordering  of  the  block  flow  matrix  BB.  To  help  with  the  trusted 
partial  ordering  we  created  a  specific  structure  for  BB.  Instead  of  creating  a  separate 
predicate  for  FLOWS  as  is  recommend  in  the  paper  we  added  the  concept  directly  to  BB. 
We  can  consider  a  read  originating  from  Block  A  to  Block  B  to  be  the  same  as  a  write 
originating  from  Block  B  to  Block  A  in  tenns  of  infonnation  flow.  We  can  simplify 
either  statement  by  saying  information  has  flowed  from  Block  B  to  Block  A.  In  our  BB 
signature  we  call  this  the  basic  flow  and  use  FLOWS  for  the  transitive  closure  of  the 
basic  flows. 

From  a  security  perspective  the  transitive  closure  is  useful  for  seeing  all  blocks 
that  infonnation  can  eventually  flow  into.  However,  as  we  mentioned  above,  in  the 
general  case  the  transitive  closure  is  not  possible  in  predicate  logic.  Our  solution  for  both 
the  BB  access  matrix  and  the  trusted  partial  ordering  predicate  TPO  involves  the 
transitive  closure  (A  carrot  symbol  in  Alloy).  It  may  be  possible  to  re-factor  both  and 
eliminate  the  need  for  transitive  closure.  Time  constraints  prevented  us  from  pursuing 
this  further. 
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3. 


PO 


We  are  interested  in  a  traditional  confidentiality  policy  between  the  blocks  that 
prohibits  reading  up  or  writing  down.  The  separation  kernel  itself  only  isolates  the 
blocks  and  regulates  the  flow  between  them,  but  is  devoid  of  semantics  labeling  one 
block  greater  than  another. 

However,  we  can  define  a  predicate  that  will  require  the  flows  between  blocks  to 
be  defined  in  such  a  way  that  information  is  not  allowed  to  flow  circularly.  That  is  if 
information  leaves  a  block,  there  is  no  transitive  flow  that  will  lead  back  to  itself.  It  is 
important  to  note  that  any  two  blocks  are  not  required  to  be  related  by  a  flow.  For 
example,  BlockA->BlockC,  BlockB->BlockC,  but  there  is  no  flow  between  BlockA  and 
BlockB  and  no  indication  if  one  is  greater  than  the  other.  Therefore  such  a  non-circular 
flow  of  infonnation  is  technically  considered  a  partial  ordering  but  not  a  total  ordering. 
That  is,  not  all  the  items  in  the  set  are  comparable. 

Mathematically  a  partial  ordering  (PO)  is  defined  as  a  relation  over  a  set  that  is 
transitive  and  antisymmetric.  Antisymmetric  means  there  is  no  circularity  in  the  relation. 
Many  authors  extend  a  partial  ordering  to  include  reflexivity  which  means  every  item  in 
the  set  is  comparable  to  itself.  We  include  reflexivity  in  PO  allowing  it  to  be  commented 
out  if  not  desired.  The  definition  in  the  paper  and  our  corresponding  specification  in 
Alloy  are  both  straight  forward  and  derived  without  complication. 

It  should  be  noted  that  one  often  hears  people  speak  of  lattices  in  information 
security.  A  lattice  is  a  partial  ordering  where  every  comparable  pair  of  items  contain  both 
a  least  upper  bound  (lub)  and  a  greatest  lower  bound  (gib),  which  results  in  a  universal 
upper  and  lower  bound  to  the  lattice. 

4.  TPO 

Overtime  an  item  of  information  may  no  longer  be  sensitive  and  its  sensitivity 
may  need  to  be  downgraded.  To  do  so  requires  violating  the  partial  ordering.  Therefore 
the  notion  of  a  trusted  subject  is  introduced.  A  trusted  subject  is  a  subject  (i.e.,  process) 
that  has  undergone  rigorous  analysis  and  is  trusted  not  to  downgrade  infonnation  other 

than  the  information  it  is  intended  to  downgrade. 
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A  trusted  subject  is  allowed  to  violate  the  partial  ordering  but  it  is  not  required  to 
violate  the  partial  ordering.  Therefore,  there  may  be  flows  in  the  system  that  are  the 
result  of  the  trusted  subjects  and  violate  the  partial  ordering.  However,  not  every  trusted 
subject  necessarily  violates  the  partial  ordering.  The  challenge  here  is  that  we  do  not 
really  have  a  way  of  identifying  which  subject,  trusted  or  otherwise,  caused  a  flow  in  bb, 
after  all,  the  matrices  are  intended  to  be  orthogonal.  However,  the  reverse  may  be 
possible.  We  can  identify  the  flows  in  sr  flow  and  require  any  flow  that  upsets  the  partial 
ordering  in  bb  to  be  a  trusted  subject.  However,  this  also  requires  us  to  identify  the 
partial  ordering. 

Figure  16  shows  our  initial  experimentation  where  we  implement  the  solution 
exactly  as  it  is  stated  in  section  5  of  the  paper  A  Least  Privilege  Model  for  Static 
Separation  Kernels  [Lev04].  This  was  both  a  major  source  of  effort  and  a  major  success 
of  our  experiment.  During  testing  the  Alloy  Analyzer  produced  models  that  did  not 
conform  to  a  trusted  partial  ordering.  We  initially  assume  that  we  had  incorrectly 
specified  the  TPO  in  Alloy  or  made  some  other  flaw  in  methodology.  We  spent 
considerable  effort  in  re-specifying  the  predicate  with  the  block-flows  Bbase  and  Bcontra 
stated  in  alternative  ways.  After  exhausting  all  these  possibilities,  we  ultimately 
determined  the  reason  for  the  inconsistency  was  not  a  weakness  of  the  Alloy  specification 
language  nor  of  the  security  policy,  but  in  the  ability  of  predicate  logic  to  clearly  describe 
the  intended  security  policy. 
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—  Trusted  Partial  Ordering  for  the  system 
pred  TPO ( s :  System,  Bbase:  BB) { 
some  Bcontra:  BB  | 

( 

s.bb.flow  =  Bbase. flow  +  Bcontra. flow  && 

PO  [Bb  ase]  £&. 

all  rs:  subject,  r:  resource,  f:  mode  | 

( 

f  in  Bcontr  a.  flow[  rs  .  master]  [r. master]  && 
f  in  s .  sr_flow  [  rs] [r]  && 
no  b :  BB  | 

( 

b . f low  =  Bbase. flow  +  (rs. master  ->  r. master 

->  f)  && 

PO[b] 

)  --  no 

=>  rs  in  trusted_sub j ect 

) — all 
)  —  some 
}  ~ TPO 


Figure  16.  TPO  As  State  In  The  Paper 

When  we  specified  the  original  documentation’s  TPO  predicate  using  the  Alloy 
specification  language  the  Alloy  Analyzer  produced  the  following  counter  example:  Two 
block-flows  that  individually  do  not  upset  the  partial  ordering,  but  when  taken  together 
do  upset  the  partial  ordering.  Understanding  this  we  constructed  an  alternative 
specification  of  the  TPO  which  more  clearly  describes  the  intended  security  policy. 

This  was  a  major  success  of  our  experimentation.  Previous  students  who  used 
tools  such  as  PVS  and  Specware  were  not  able  to  attempt  modeling  the  TPO  due  to  tool 
complexities.  Consequently  this  issue  went  undiscovered.  The  major  difference  in  our 
solution’s  approach,  as  seen  in  Figure  17,  from  that  of  the  paper  is  that  our  approach  tests 
the  entire  set  of  non-trusted  flows  while  the  paper  attempts  to  identify  each  trusted  flow 
one  at  a  time.  Unfortunately  this  results  in  the  partial  ordering  being  identified  via  the  SR 
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least  privilege  matrix.  This  may  have  the  same  effective  result,  but  weakens  the  concept 
of  SR  and  BB  being  entirely  orthogonal  and  makes  visualizing  the  trusted  partial  ordering 
via  BB  difficult.  As  a  precaution  we  included  the  transitive  closure  in  our  solution. 


--  Trusted  Partial  Ordering  for  the  system 

pred  TPO(sys:  System)  { 

let  Nontrusted_Subs_in_SR  =  dom[ sys . sr_f low]  - 

Trusted_Subj  ect, 

Nontrusted_Block_Flow  = 

{ 

bl,  b2 :  Block,  m:  Mode  | 

( 

same  sub:  Nontrusted_Subs_in_3R, 

r:  Resource  | 

t 

--  sub  is  a  non- trusted  subject  in  the 
--  subject  part  of  sr_flow,  when  combined 
--  with  some  resource  and  the  mode  of 
--  Nontrusted_Block_Flow  is  also  in 

—  sr_£low 

(sub  ->  r  ->  m)  in  sys. sr_flow  &£ 

--  and  the  corresponding  blocks  of  that 

--  subject  and  resource  comprises  the 

—  blocks  of  Nontrusted_Block_Flow 

bl  =  sub. master  && 
b2  =  r. master 
)  —  some 

) 

}  |  —  def  of  Nontrusted_Subs_in_3R 

--  The  transitive  closure  of  the  intersection  of 
--  the  Nontrusted_Block_Flow  and  bb.flow  with  the 
--  Mode  removed  should  be  a  partial  ordering 

PO [  A ( (Montrusted_Block_Flow  £  sys. bb.flow) .Mode)] 


Figure  17.  Our  TPO 
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C.  CONCLUSION 

The  security  of  the  system  is  defined  in  terms  of  as  information  flows  constrained 
by  two  access  matrices,  one  of  which  conforms  to  a  trusted  partial  ordering.  Except  for 
minor  issues,  specifying  the  FSPM  in  Alloy  went  smoothly.  The  major  stumbling  block 
was  not  the  Alloy  environment,  but  the  fonnal  definition  of  a  trusted  partial  ordering. 
The  major  effort  in  overcoming  this  was  not  grappling  with  the  Alloy  specification  or  the 
Alloy  Analyzer,  but  in  grappling  with  our  assumption  of  the  formal  definition  of  the 
TPO.  The  fact  this  issue  has  gone  unnoticed  before  our  experimentation  has 
demonstrated  that  Alloy  is  not  only  useful  for  the  novice,  but  for  the  more  seasoned 
formal  methods  developer  as  well. 
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V.  EXTENDED  MODELS 


A.  SECURITY  FRAMEWORK 

In  the  formal  methods  process  the  formal  top  level  specification  (FTLS)  is  a  high 
level  design  specification  that  represents  a  refinement  of  the  abstract  concepts  and 
properties  of  the  policy  model  (FSPM)  in  the  form  of  a  general  blue  print  towards 
building  the  actual  system.  The  goal  of  the  formal  methods  development  process  is  to 
prove  that  the  FTLS  accurately  represents  the  system  in  its  entirety  while  preserving  the 
properties  of  the  FSPM.  The  separation  kernel  model  that  we  built  in  section  IV 
represents  the  FSPM  of  the  separation  kernel.  Alloy  allows  for  a  gradual  incremental 
development  style.  We  can  reuse  the  separation  kernel  Alloy  specification  unaltered  in  a 
new  augmented  Alloy  specification.  This  augmented  specification  corresponds  to  a 
FTLS.  Since  it  is  nothing  more  than  an  augmentation  of  the  FSPM  specification  we  can 
declare  that  it  represents  the  FSPM  in  its  entirety. 

Demonstrating  that  the  FSPM  properties  have  been  preserved  in  the  FTLS 
presents  an  interesting  problem.  We  are  interested  in  discovering  insecurities  in  the 
design  and  implementation  of  the  operating  system.  A  traditional  way  to  formally 
represent  the  security  of  a  system  is  with  a  state  transition  model,  where  inputs  on  a  state 
define  a  transition  to  a  new  state.  By  defining  a  set  of  possible  inputs  and  an  initial  state 
we  can  model  all  reachable  states.  Additionally,  by  defining  what  makes  a  state  valid  or 
invalid  we  can  check  if  any  of  the  reachable  states  are  invalid  states,  as  well  as  identify 
invalid  state-to-state  transitions. 

In  our  FSPM  model  our  System  signature  and  matching  Secure  predicate 
naturally  correspond  to  states  and  their  definition  of  validity.  An  infonnal  system 
interface  document  defines  the  operations  that  can  occur  in  the  system.  We  use  these 
interface  operations  for  our  set  of  inputs.  By  declaring  our  initial  system  secure,  we 
check  to  see  if  any  of  the  interface  operations  (inputs)  lead  to  an  insecure  system.  If  all 
inputs  result  in  secure  states,  the  system  is  said  to  be  “Secure”.  This  is  often  referred  to 
as  the  basic  security  theorem. 


25 


We  created  a  Command  signature  to  characterize  the  operations  and  related 
parameters  and  specified  a  subset  of  the  actual  operations.  All  the  system  operations 
have  the  ability  to  return  error  codes,  as  do  the  corresponding  commands.  In  our  initial 
experimentation  we  used  the  System  signature  alone  to  represent  a  state.  This  made  it 
difficult  to  take  advantage  of  the  visualization  ability  of  Alloy.  Therefore,  we  created  a 
Transition  signature  to  encapsulate  the  state  and  the  inputs  as  seen  in  Figure  18.  Alloy 
has  a  built-in  type  to  represent  the  universal  set.  This  pennits  any  type  in  the  model  to 
belong  to  the  set,  and  enables  our  expression  of  state  transitions. 


—  List  of  commands  in  the  preliminary  interface, 
abstract  sig  Command  {} 
one  3ig  no_op_coin, 
read_com, 
wr ite_com 
extends  Command  {} 

--An  error  for  each  command 
abstract  sig  Error  {  } 
one  sig  no_err, 

read_err , 
wr ite_er r 
extends  Error  {} 

sig  Transition 

< 

error  message:  Error, 
last_command:  Command, 

arguments:  set  univ, 

sys:  System 

) 


Figure  18.  Transition  Signature  In  runtime. als 


We  encountered  two  issues  when  attempting  to  model  Transition  sequences.  In 
our  original  experimentation  we  used  the  default  ordering  module.  The  ordering  module 
constrains  every  element  of  the  set  being  ordered  to  exist  in  the  ordering.  Consequently 
only  one  ordering  is  allowed.  One  potential  difficulty  the  ordering  module  may  have 
presented  would  have  been  in  connecting  the  last  state  of  the  initialization  module  with 
the  first  state  of  the  runtime  module.  After  several  trials  experimenting  with  the  ordering 
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module  we  encountered  issues  due  to  its  subtleties.  Consequently  we  abandoned  it  and 
chose  to  use  the  sequence  module  in  its  stead  as  seen  in  Figure  19. 


—  For  state  transitions 

open  util/sequence [Transition]  as  run  time  seq 

Figure  19.  Declaration  Of  Sequence  In  runtime. als 

The  sequence  module  had  its  own  subtleties  that  cost  us  a  noticeable  amount  of 
time  to  resolve.  Unlike  the  ordering  module,  elements  may  exist  in  the  model  that  have 
no  corresponding  index  to  a  sequence.  Also,  their  may  be  more  than  one  sequence  to  a 
model.  To  ensure  that  state  transitions  extraneous  to  a  sequence  did  not  interfere  with  the 
model,  it  seemed  reasonable  to  simply  declare  that  every  state  transition  was  included  in 
the  sequence  and  then  check  to  see  if  every  reachable  state  was  secure  as  seen  in  Figure 
20.  However,  when  multiple  sequences  were  created  in  the  model  a  state  transition  in 
one  of  the  sequences  would  interfere  with  another  sequence  creating  inconsistencies  in 
the  model.  For  this  reason  we  limit  the  number  of  sequences  to  exactly  one  as  seen  in 
Figure  2 1 . 


—  no  transitions  outside  of  the  sequence 
fact  every_transition_in_sequence 

< 

Transition  in  run_t ime_seq/ Seq : : elems [] 

} 

assert  SecureTrans 

< 

all  t:  Transition  |  Secure [t . sys] 

} 

check  SecureTrans  for  3 


Figure  20.  All  Transitions  In  The  Sequence 


—  Without  this  constraint  transitions  interfere 

—  with  different  sequences 
fact  exact ly_one_sequence 

{ 

one  Seq 

t 


Figure  2 1 .  Only  One  Sequence  In  The  Model 
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B. 


TWO  SEPARATE  MODELS 


Our  interface  design  document  has  essentially  broken  the  system  down  into  two 
distinct  but  connected  sub-systems.  One  that  represents  the  system  at  the  point  it  is 
initialized  and  another  that  represents  system  during  runtime,  in  a  fully  functional 
capacity.  Consequently  we  developed  two  distinct  Alloy  specifications  to  represent  the 
FTLS  as  distinct  sub-systems.  The  connectedness  of  the  two  systems  can  be 
demonstrated  by  having  the  last  state  of  the  initialization  FTLS  be  the  first  state  of  the 
runtime  FTLS,  as  seen  in  Figure  22.  Both  incorporate  the  FSPM  in  its  entirety,  so  the 
connection  of  each  FTLS  with  the  FSPM  is  implicit. 


L>  Transition 

-77  Refinement  Property  Perserving 


Figure  22.  Relationship  Of  Models 

To  facilitate  the  connection  between  the  two  we  added  unused  constructs  in  one 
model  to  the  other.  The  major  difference  between  the  two  models  is  the  final  two  facts. 
The  first  fact  declares  the  initial  state  of  model.  Figure  23  shows  the  specification  fact 
for  declaring  the  first  state  of  the  init  model  consisting  of  empty  matrices  and  Figure  24 
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shows  the  specification  fact  for  declaring  first  state  of  the  runtime  model  consisting  of 
established  matrices.  The  second  fact  in  each  model  defines  a  transition  in  the  system  as 
any  of  the  allowed  operations  occurring.  We  then  write  separate  predicates  for  each 
operation  which  allows  for  either  success  or  failure  of  the  operation.  Alloy  has  a 
construct  for  if  then  else  which  we  used  in  the  transition  fact  to  articulate  the  system 
response  whether  or  not  the  operation  was  successful. 


fart  init_set_up_seq  { 
let  t  =  S eq: :  s et_up_s eq/firs  t[]  | 

no_err  —  t.  e  rror_m  essage  &  & 
no_°p_c°m  =  t.last_command  && 
no  t.  arguments  && 

no  t.  sys. re  sources  && 
no  t.  sys. bb.  flow  && 
no  t.sys.sr_tlow  && 
no  t.  sys. MM 

) 


F igure  23.  Init  Fact 


fact  imt_run_time 

{ 

let  t  =  Seq::run_time_seq/first[] 

no_err  =  t  e  rr  or_m  e  s  s  ag  e  &  & 
no_op_com  =  t.last_command  && 
no  t.  arguments  && 

Secure[t.  sys] 

} 


Figure  24.  Runtime  Fact 


We  are  modeling  a  static  separation  kernel.  This  means  that  the  allowed 
information  flows  remain  unchanged  while  the  system  is  up  and  operational.  However, 
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while  the  system  is  being  initialized  the  allowed  infonnation  flows  are  configured  for  the 
first  time.  Therefore,  in  the  runtime  model  none  of  the  matrices  are  allowed  to  change. 
However,  in  the  initialization  model  we  start  with  empty  matrices  and  fill  the  matrices  in 
until  the  initialization  phase  completes. 

1.  The  Runtime  Model 

The  interface  document  has  various  operations  all  dealing  essentially  with 
memory  segments.  From  a  security  perspective  what  we  are  ultimately  concerned  with  is 
the  flow  of  memory.  The  most  basic  operation  in  the  interface  is  reading  or  writing  a 
byte  of  memory.  Being  a  static  kernel,  resource  allocation  does  not  occur  during  run¬ 
time.  Therefore,  we  only  modeled  a  read  and  a  write  operation.  In  order  to  simplify  the 
modeling  of  reading  and  writing  we  declared  a  signature  Memory  Segment  independent 
of  the  Resource  signature.  We  left  processes  and  resource  handles  out  of  this  model. 
Figure  25  shows  a  relation  we  added  to  the  System  signature  that  maps  every  resource  in 
the  system  to  a  memory  segment.  A  successful  read  or  write  will  update  this  relation 
accordingly.  Extensions  to  deal  with  non-memory  objects  are  left  for  future  work. 

Only  subjects  are  allowed  to  initiate  a  memory  flow  in  our  model.  When  a 
subject  reads  a  byte  of  memory  from  another  resource  it  is  overwriting  one  of  its  own 
bytes  of  memory  with  one  of  the  resources  bytes  of  memory.  Likewise,  when  a  subject 
writes  a  byte  of  memory  it  is  overwriting  one  of  the  resource’s  bytes  of  memory  with  one 
of  its  own.  By  removing  and  adding  subject  and  resource  memory  segments  to  the 
resource  memory  segment  relation  in  the  system  signature  appropriately  we  can  model 
the  flow  of  information  exactly.  In  Figure  26  sys  represents  the  current  state  system  and 
sys’  the  state  of  the  system  after  modification. 


RM:  resources  ->  Hemory_Segment 


Figure  25.  Added  To  The  System  Signature 
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--  read  memory  modification  occurs 

sys'.RM  =  ( (sys.RM) - (sub->segS) )  +  (suto->segR) 

--  write  memory  modification  occurs 

sys'.RH  =  (  (sys . RH) - (res->segR)  )  +  (res->segS) 


Figure  26.  Read  And  Write  Defined 

2.  The  Initialization  Model 

In  our  first  fact  we  declare  all  the  matrices  to  be  empty.  In  the  second  fact  we 
allow  any  of  the  initialization  operations  that  affect  the  matrices  to  occur  in  any  order. 
This  allows  the  matrices  to  be  gradually  filled  in  one  operation  at  a  time. 

In  this  model  we  added  signatures  for  the  ResourcelD  and  PartitionID  in  order  to 
align  the  specification  with  our  interface  document.  We  added  them  to  the  runtime 
model  also  in  order  to  maintain  similarities  between  the  models.  In  the  initialization 
model  we  made  Memory_Segments  an  extension  of  Resources.  Memory_Segments  have 
children  and  we  placed  constraints  on  the  memory  structure  to  be  strictly  hierarchical. 
Processes  are  extensions  of  subjects.  We  create  a  handle  signature  to  represent  a  local 
descriptor  table  in  a  process.  We  added  a  Partition  Flow  Vector,  Resource  Vector,  and 
Partition  Resource  Vector  to  represent  parameters  of  the  operations. 

We  had  one  major  difficulty  in  this  model.  Declaring  the  last  command  and 
arguments  location  seen  in  Figure  27  caused  inconsistencies  in  the  model.  Moving  the 
declarations  as  we  did  in  Figure  28  removed  the  inconsistencies.  We  are  unsure  as  to 
why  this  is. 
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Figure  27.  Previous  Experimentation 


F igure  28.  F inal  Experimentation 
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C.  CONCLUSION 

We  set  out  to  create  a  mapping  between  a  FTLS  and  FSPM  representation  of  the 
separation  kernel.  Alloy  does  not  have  built-in  constructs  for  the  mapping  of  a 
specification  to  a  refinement  of  that  specification.  However,  by  incorporating  the 
specification  in  the  FSPM,  its  properties  are  retained  in  the  FTLS  models.  To  prove  that 
operations  preserve  the  properties  of  the  models  we  used  the  traditional  basic  security 
theorem,  which  is  essentially  a  proof  by  induction.  In  the  future  work  section  we  discuss 
how  the  native  Alloy  tools  can  be  used  to  implement  specification  refinement  mapping. 

The  usability  of  the  tool  allowed  us  to  implement  much  more  of  the  model  than 
previous  efforts  with  theorem  provers.  We  encountered  some  difficulties  with  the  tool, 
but  these  were  more  attributable  to  the  complexities  of  predicate  logic  than  the  Alloy  tool 
itself.  The  more  operations  we  added  to  the  model  the  more  computationally  intensive  it 
became  for  the  Analyzer  to  process  the  model.  Consequently  the  largest  scope  we  could 
achieve  in  the  initialization  model  was  a  scope  of  three.  In  this  respect  the  current 
version  of  the  Alloy  toolset  was  inadequate.  We  have  seven  possible  inputs,  but  the 
analyzer  is  only  able  to  test  any  combination  of  three  of  them.  A  much  larger  scope 
would  be  necessary  to  reasonably  assume  that  for  this  larger,  but  nonetheless  limited 
scope,  we  have  demonstrated  the  security  of  the  model. 


33 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


34 


VI.  CONCLUSION  AND  FUTURE  WORK 


A.  EVALUATION  CRITERIA 

Table  1  presents  evaluation  criteria  for  the  analysis  of  a  verification  tool  originally 
produced  by  Ubhayakar  [Ubh03]  and  extended  by  DeCloss  [Dec06]  for  the  TCX  project. 

Being  a  model  analyzer  Alloy  can  not  prove  theorems.  Therefore  we  must  look  at 
Alloy  differently  in  order  to  evaluate  its  theorem  analysis  and  conjecture  generation 
abilities.  Assertions  in  Alloy  are  analogous  to  theorems  and  can  be  verified  within  a 
limited  scope  as  we  discussed  regarding  the  small  scope  hypothesis.  When  any  counter 
example  is  found  to  an  assertion  a  visual  model  is  produced.  If  no  counter  example  is 
found  then  no  model  is  produced.  This  automated  validation  of  assertions  would  be 
analogous  to  automated  theorem  proving.  However,  Alloy  has  the  added  advantage  of 
allowing  the  user  to  visually  inspect  the  model  to  more  fully  understand  the 
inconsistency.  In  general  the  user  can  always  visually  inspect  a  specification  by  running 
any  predicate.  Therefore  Alloy  ranks  high  in  the  area  of  executable  specifications. 

The  Alloy  specification  language  has  an  incredibly  low  learning  curve.  Basic 
understanding  of  predicate  logic  and  set  theory  is  all  that  is  required.  People  who  work 
specifically  in  formal  verification  and  computer  science  generally  already  possess  a  solid 
understanding  these  concepts.  At  most  a  refresher  in  the  join  operation  and  a 
familiarization  of  the  multiplicity  syntax  of  Alloy  is  required.  A  small  set  of  libraries  that 
perform  common  functions  is  provided  with  the  default  download.  As  the  tool  matures 
we  expect  a  richer  set  of  libraries  to  be  developed.  Therefore  Alloy  ranks  extremely  well 
regarding  its  specification  language,  usability,  and  extensibility. 
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Evaluation  Criteria 

Definition 

Utility 

Product  Maturity 

A  tool  should  be  old 
enough  and  currently 
maintained  and  supported 

Specific  questions  need  to 
be  answered  in  a  timely 
manner  regarding  syntax 
and  specification  language 

Usability  of  Tool  and 
Verification  Environment 

The  level  of  simplicity  and 
flexibility  of  operations 
provided  to  the  user 

The  interface  and 
commands  should  be 
simple  to  understand  and 
should  provide  syntax 
highlighting  and  error 
checking  to  increase 
efficiency 

Theorem  Proving 

Interactive  versus 
automated  theorem 
proving 

Theorem  proving  should  be 
easily  integrated  and 
provide  meaningful 
descriptions  of  errors  and 
logging  capabilities 

Specification  Language 

Syntactical  elements  of  the 
language 

Learning  cur\>e  associated 
with  language  should  be 
minimal  to  provide 
efficient  generation  of 
specifications 

Executable  Specifications 

Ability  to  test  system 
directly  from  specification 
language 

Executable  specifications 
provide  the  user  with  a 
general  “feel”  for  the 
system 

Multiple  Levels  of 
Abstraction 

Refinement  capabilities 
from  more  abstract 
specifications  to  more 
concrete  specifications 

Multiple  levels  of 
abstractions  provides 
ability  to  verify  that  the  top 
level  specification  satisfies 
security  policy 

Automatic  generation  of 
Conjectures 

Ability  to  automatically 
state  items  which  must  be 
proven 

This  aids  in  ensuring  that 
all  obligations  regarding 
the  system  are  being 
addressed 

Semantics 

Powerful  expression  of 
logic  with  minimal 
complexity 

Underlying  logic  and 
foundational  theory ?  affects 
the  expressiveness  of  the 
tool  regarding  system 
properties 

Table  1.  Evaluation  Criteria 
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Much  like  an  object  oriented  programming  language,  Alloy  is  naturally  suited  for 
multiple  levels  of  abstraction.  With  the  ‘ extends ’  and  ‘ abstract ’  keywords  a  specification 
can  be  reused  to  create  more  concrete  models.  This  specification  reuse  almost  fulfills  the 
definition  of  a  morphism  [Spe04],  but  falls  short.  Since  the  demonstration  of  a  morphism 
is  not  a  built  in  feature  there  can  not  be  automatic  generation  of  conjectures.  In  the  future 
work  section  we  discuss  how  to  use  Alloy  to  completely  demonstrate  morphisms. 
Nonetheless,  Alloy  is  naturally  suited  for  multiple  levels  of  abstraction  and  ranks  well  in 
this  area. 

Alloy  is  a  semi-higher  order  logic  system,  but  is  not  fully  capable  of  higher 
ordered  logic.  For  the  most  part  this  is  not  a  problem.  In  many  occasions  a  problem 
stated  in  higher  order  logic  can  be  restate  in  first  ordered  logic.  The  built  in  operator  for 
the  transitive  closure  helps  in  avoiding  higher  ordered  logic.  Nonetheless,  compared  to 
some  other  tools  the  semantics  of  Alloy  are  technically  less  expressive. 

Alloy  is  a  relatively  new  tool,  but  is  developing  support  rapidly.  It  was  developed 
at  Massachusetts  Institute  of  Technology  (MIT),  a  world  renowned  university.  It  has 
gained  in  popularity  rapidly  with  a  large  support  community  emerging.  Questions  to  the 
Alloy  community  discussion  group  are  thoughtfully  responded  to  within  24  hours.  The 
discussion  group  and  website  are  well  maintained  by  the  research  students  at  MIT.  Alloy 
does  not  require  training  courses,  though  the  website  contains  excellent  tutorials  and  user 
manuals.  Alloy’s  conceiver  and  promoter  Daniel  Jackson  wrote  a  textbook  about  Alloy 
titled  “Software  Abstractions.”  However,  it  was  published  only  recently  in  2006.  The 
Alloy  community  held  its  first  conference  in  November  of  2006.  The  conference  was 
well  attended  by  academic,  industry,  and  government  researchers. 

We  would  like  to  rank  Alloy  high  in  product  maturity,  but  its  short  history 
prevents  us  from  doing  so.  For  example,  during  our  experimentation  we  witnessed  an 
update  from  Alloy  3  to  Alloy  4.  This  update  simplified  the  Alloy  installation.  However, 
the  update  contained  some  irksome  syntax  changes. 

The  Alloy  Analyzer  operates  with  in  a  GUI  interface  with  one  window  for  editing 
the  specification  and  another  for  compilation.  A  button  will  open  another  window  for 
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visualizing  the  model  in  a  variety  of  forms.  Unfortunately  the  Alloy  Analyzer  GUI  editor 
does  not  offer  syntax  highlighting.  This  is  the  one  major  fault  of  the  tool.  The  discussion 
group  contained  dialog  of  users  implementing  syntax  highlighting  with  the  java  IDE 
environment  Eclipse.  We  expect  that  as  the  tool  matures  syntax  highlighting  will  become 
a  native  component  of  the  Alloy  Analyzer. 

Overall  the  tool  ranks  well  with  our  evaluation  criteria.  Its  major  drawback  is 
product  maturity,  but  this  is  sure  to  be  solved  with  time. 

B.  RESULTS 

We  have  demonstrated  that  Alloy  is  an  important  tool  to  include  in  the  toolbox  of 
rapid  high  assurance  development.  Its  low  learning  curve  allows  for  the  beginner  to 
formal  methods  and  high  assurance  systems  to  quickly  hone  their  development  skills. 
While  we  did  not  specify  the  FSPM  and  the  FTLS  in  their  entirety,  this  was  not  a  fault  of 
Alloy  itself,  but  the  time  constraints  of  a  master’s  level  thesis.  With  the  work  we  have 
completed  so  far  it  is  reasonable  to  believe  that  an  additional  quarter’s  thesis  slot  would 
produce  a  richer,  fuller  model  that  includes  internal  resources,  exported  resources,  time 
slices,  and  dynamic  features  of  the  TCX  LPSK.  Our  most  exciting  result  is  that  Alloy 
proved  itself  useful  even  for  more  seasoned  developers. 

The  weakness  we  discovered  in  the  TPO  has  proven  Alloy’s  definite  development 
value.  Additionally,  Alloy  is  naturally  suited  for  demonstrating  morphisms.  However,  it 
does  not  have  built-in  constructs,  libraries,  or  templates  for  doing  so.  Our  approach  of 
including  the  FSPM  within  the  FTLS  to  demonstrate  security  in  the  FTLS  was  useful  to 
the  current  developers  of  the  TCX  LPSK.  However,  this  approach  does  not  fully  satisfy 
the  definition  of  morphism  in  the  truest  sense.  In  the  future  work  section  below  we  give  a 
more  precise  definition  of  morphism  and  give  an  example  of  how  to  demonstrate  one  in 
Alloy. 


C.  FUTURE  WORK 

The  Specware  4.1  Tutorial  [Spe04]  contains  an  excellent  explanation  of 
morphisms.  “A  morphism  is  a  mapping  from  a  source  spec  to  a  target  spec.  More 
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precisely,  it  consists  of  two  functions:  one  maps  each  type  symbol  of  the  source  to  a  type 
symbol  of  the  target,  and  the  other  maps  each  op  symbol  of  the  source  to  an  op  symbol  of 
the  target.”  Alloy  is  naturally  suited  to  demonstrate  morphisms  by  reusing  specifications. 
The  nature  of  extending  a  signature  creates  mapping  each  type  symbol.  Therefore,  in 
Alloy  simply  by  reusing  a  specification  the  first  function  of  a  morphism  has  been 
satisfied.  However,  there  remains  the  effort  of  proving  that  the  properties  of  the  source 
specification  operations  are  retained  in  the  target  specification  operations.  Figure  29 
demonstrates  how  to  do  this  in  Alloy  using  the  natural  numbers  and  commutativity 
example  given  in  the  Specware  tutorial.  For  future  work  we  recommend  further 
investigating  this  approach.  The  level  of  difficulty  and  effectiveness  in  using  this 
approach  with  the  TCX  LPSK  would  be  an  interesting  analysis  for  the  TCX  project. 
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Source  Specification 

/***************************»**»********************************»******»**»***/ 

one  sig  Nat  ■ 

rel:  Nat->IJat->Nat 

> 

pred  op  (nl,  n2,  n3 :  Nat)  { 

(nl->n2->n3)  in  (Nat. rel) 

> 

fact  coirtmunative  { 

all  nl,  n2,-  n3 :  Nat  | 

op[nl,  n2,  n3]  <=>  op[n2,  nl,  n3] 

> 


/******************* *****************************************  ****************** 
Target  Specification 

/*****************************************************************************/ 

sig  X  extends  Nat  {} 

pred  opx(xl,  x2 ,  x3 :  X)  < 
op[xl,  x2,  x3] 

—  further  operation  definition  would  go  here 

> 

assert  morphism{ 

all  xl,  x2,.  x3 :  X  | 

opx[xl,  x2,  x3]  <=>  opx[x2,  xl,  x3] 

) 

check  morphism 


Figure  29.  Morphism  With  Alloy 
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APPENDIX  A:  SEPARATION  KERNEL  FSPM  IN  ALLOY 


z  * **************************************************************************** * 

A  Least  Privilege  Model  for  Static  Separation  Kernels 
from  T. Levin,  C. Irvine,  T. Nguyen,  Cl  SR  Tech  Report  NPS-  CS-  05  -  003 
October  2004 

(references  to  the  Tables  in  the  paper) 

****************************************************************************** i 

module  sepker  nel 

--  library  containing  the  domfunction 
open  ut i I / 1  er  nar  y  as  tern 


/  * **************************************************************************** * 

The  information  in  computer  systems  is  often  thought  of  generi  cal  I  y  as 
resources.  The  flow  of  information  is  then  described  as  a  matrix  of  what 
resource  is  allowed  to  read  and/or  write  to  another  resource.  This  is 
referred  to  as  an  access  matrix.  A  resource  is  anything  in  the  systemwe  wish 
to  consider,  be  it  a  file,  a  process,  a  user,  a  program,  firmware,  etc.  In 
Alloy  a  3-tuple  or  3  item  relation  can  be  used  to  indicated  the  access  matrix 
like  so,  Resource  ->  Resource  ->  Mode  The  'abstract'  keyword  below  indicates 
that  an  item  called  Mode  should  not  be  created  in  the  model.  The  'extends'  and 
'abstract'  keywords  are  analogous  to  object  oriented  programming  with  a 
heirarchy  of  parent  and  child  classes.  The  'one'  keyword  means  one  and  only 
one  item  called  RD  and  one  and  only  one  item  called  WT  should  be  the  mo  del. 

****************************************************************************** i 

-  -  R  in  the  paper 
s i  g  Resource 
{ 

--  Every  Resource  belongs  to  exactly  one  Block,  no  more,  no  less 
master:  one  Block 

} 


-  -  access  rights  type,  F  in  the  paper 
abstract  sig  Mode  {} 

-  -  read  and  wr  i  t  e  in  the  Paper 
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one  sig  R D ,  WT  extends  Mode  {} 


/  * **************************************************************************** * 

A  separation  kernel  partitions  all  the  resources.  The  separation  kernel  is 
simplistic  in  that  it  only  provides  the  isolation  of  resources  into  partitions 
which  we  will  call  Blocks.  In  the  system  every  Resource  will  be  assigned 
exactly  one  and  only  one  Block,  thus  the  Blocks  represent  equivalence  classes 
of  Resources.  Our  separation  kernel  will  be  static,  therefore  there  will  be 
no  reassigning  of  Resources  to  different  Blocks  once  the  kernel  is  running  and 
it  will  not  make  sense  to  have  empty  Blocks.  It  is  not  useful  to  have  all 
resources  partitioned  into  a  single  Block  so  that  case  may  be  explicitly 
excluded  from  the  model  in  order  to  make  it  mo  re  interesting. 

****************************************************************************** i 

-  -  B  in  the  paper 
sig  Block  { } 

--  each  block  has  at  least  one  resource,  no  empty  blocks 

{ 

so  me  r:  Resource  |  r.master  =  this 

} 


--  a  minimally  useful  kernel,  this  fact  may  be  commented  out 
fact  {  #  B 1  o  c  k  >  1  } 


/  * **************************************************************************** * 

The  system  will  contain  two  ma trices.  One  to  represent  the  flow  of  information 
between  blocks  and  one  for  the  flow  of  information  between  resources.  The  two 
matrices  are  intended  to  orthogonal,  that  is,  there  may  be  flows  allowed  in  one 
that  are  not  allowed  in  the  other.  We  will  be  interested  in  taking  the  partial 
ordering  and  the  trusted  partial  ordering  of  the  block  flow  matrix.  To  help 
with  the  trusted  partial  ordering  we  create  the  structure  below. 

We  can  consider  a  read  originating  from  BlockA  to  BlockB  to  be  the  same  as  a 
write  originating  from  BlockB  to  BlockA  in  terms  of  information  flow.  We  can 
simplify  either  statement  by  saying  information  has  flowed  from  BlockB  to 
Bl  o c  k A . 

Alloy  has  a  built  in  command  A  (carrot)  for  constructing  transitive  closures. 
The  transitive  closure  is  useful  for  seeing  all  blocks  that  information  can 
eventually  flow  into. 
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******************************************************************************  I 


--  Bl  ock-To-  Bl  ock  Flow  Matrix,  Table  1 
s  i  g  B  B  { 

flow:  Block  -  >  Block  -  >  Mode, 

--  these  are  secondary,  derived  from  the  flow 
basi  c_fl  ow:  Block  -  >  Block, 

FLOWS:  Bl  ock  -  >  Bl  ock 

} 

{ 

--  definition  of  basic  flow 
basi c_fl ow  = 

{ 

a ,  b  Block  | 

WT  in  f  I  ow[  a]  [  b]  or 
RD  in  f  I  ow[  b]  [  a] 

} 


FLOWS  is  a  transitive  closure  of  basi  c_f  I  ow 
F  L  OWS  =  A  basi  c_fl  ow 

These  two  are  for  better  visualizing  and  more  interesting  models 

block  always  can  access  itself  with  Read/Write 
all  b:  Block  |  #b .  (  b .  f  I  o  w)  =  #Mod  e 

each  access  mode  is  represented  at  least  once  in  the  elements  of  flow 
RD  in  Block. (Block. flow) 

WT  in  Block. (Block. flow) 


/  * **************************************************************************** * 

The  word  subject  and  object  are  typically  used  to  indicate  which  resource  is 
the  active  entity  performing  the  read  and/or  write  on  another  passive  resource. 
In  our  model  we  use  the  Subject  terminology  and  we  allow  one  Subject  to 
operate  on  another  Subject  (ie.  one  process  communicating  to  another  process). 
We  drop  the  Object  nomenclature  and  simply  refer  to  a  Subject  accessing  a 
Resource  (which  may  be  another  Subject). 

****************************************************************************** i 
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s i  g  Subject  extends  Resource  { } 


/  * **************************************************************************** * 

Our  system  is  really  rather  simple.  It  is  two  access  matrices.  One  is  the 
block  flow  (  bb)  and  the  other  the  least  privilege  matrix  ( s  r  _  f  I  o  w)  which 
constrains  the  block  flow  (bb).  Later,  we  will  define  a  secure  system  to  be  a 
systemthat  only  allows  flows  that  are  permitted  by  both  matrices.  Technically 
s  r  _  f  I  o  w  is  not  required  to  be  a  subset  of  bb.  That  is,  it  may  allow  flows  that 
are  prohibited  by  bb,  however,  in  a  secure  systemthose  flows  would  never  be 
realized,  because  what  is  allowed  is  only  the  intersection  of  the  two  matrices. 

A  Block  may  contain  any  combination  of  Subjects  and  Resources.  Therefore,  the 
Block  nomenclature  is  devoid  of  the  Subject  and  Resource  distinction.  in 
order  to  better  visualize  and  talk  about  the  flow  of  information  only  Subjects 
are  allowed  to  read  and/or  write.  That  is  Resources  that  are  not  Subjects 
should  never  initiate  a  flow. 

Of  course  we  are  only  interested  in  Resources  and  Blocks  that  are  inside  of  our 
System.  Sense  all  Resources  belong  to  a  Block,  Alloy  will  not  produce 
Resources  or  Blocks  that  have  nothing  to  do  with  each  other.  In  like  manner  we 
need  to  instruct  Alloy  that  every  block  participates  in  the  Systemto  prevent 
Alloy  from  producing  models  with  Resources  and  Blocks  that  are  outside  of  the 
System. 

MM  should  be  orthogonal  to  SR  and  BB,  that  is  SR/BB  is  the  policy  of  what  is 
allowed,  and  MM  is  what  the  program  wants  to  do.  The  security  predicate  will 
say  that  a  secure  system  allows  only  the  p r og r a m  a c t i  o n s  that  conformto  the 
pol  i  cy. 

It  is  important  to  note  that  information  is  not  required  to  flow  into  or  out  of 
a  Block.  However,  a  completely  isolated  Block  would  not  be  useful. 

****************************************************************************** i 

s i  g  System  { 
bb:  BB, 

s r _ f  I  ow:  Subj  ect  -  >Resource  -  > Mo d e , 

MM:  Subject  ->  Resource  ->  Mode 


Every  Block  participates  in  the  System. 

Block  in  B I  oc  k .  (  (  b  b .  f  I  o  w)  .  Mod  e )  +  (  (  bb.  fl  ow) .  Mode)  .  Bl  ock 
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s  r  _  f  I  o  w  is  non  empty 
s  o  me  s  r  flow 


/* 

&& 

--  This  constraint  is  only  to  create  interesting  models.  It  is  recommend  to 
--  comment  out  this  section  to  study  the  model  the  way  it  was  intended. 

--  A  completely  isolated  Block  is  not  useful  therefore: 

--  Every  block, 
all  bl:  blocks 

--  has  so  me  other  block, 
so  me  b  2 :  Block 

--  that  is  not  itself, 
d i  s  j  [ b 1 ,  b  2 ]  && 

( 

■  ■  which  it  neither  f  I  o  ws  into, 
b2  in  bl.  f  I  ow  or 
-  -  nor  out  of . 
b2  in  f  I  ow.  bl 

) 

*1 

} 

/  * **************************************************************************** * 

We  are  interested  with  a  traditional  confidentiality  policy  between  the  Blocks 
that  prohibits  reading  up  or  writing  down.  The  separation  kernel  itself  only 
isolates  the  Blocks  and  regulates  the  flow  between  them,  but  is  devoid  of 
semantics  labeling  one  Block  greater  than  another. 

However,  we  can  define  a  predicate  that  will  require  the  Blocks  to  be 
partitioned  in  such  a  way  that  information  is  not  allowed  to  flow  circularly. 
That  is  if  information  leaves  BlockA,  there  is  no  transitive  closure  of  the 
flows  that  will  lead  back  to  BlockA.  It  is  important  to  note  that  any  two 
Blocks  are  not  required  to  be  related.  For  example,  Bl  ockA-  >BI  ockC, 

Bl  ockB-  >BI  ockC,  but  there  is  no  flow  between  BlockA  and  BlockB  and  no 
indication  if  one  is  greater  than  the  other.  Therefore  such  a  non-circular 
flow  of  information  is  technically  considered  a  partial  ordering  but  not  a 
total  ordering.  That  is,  not  all  the  items  in  the  set  are  comparable. 

Mathematically  a  partial  ordering  (  PO)  is  defined  as  a  relation  over  a  set  that 
is  transitive  and  antisymmetric.  Antisymmetric  means  there  is  no  circularity 
in  the  relation.  Many  authors  extend  a  partial  ordering  to  include  reflexivity 
which  means  every  item  in  the  set  is  comparable  to  itself.  In  our  situation 
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this  may  or  may  not  be  the  case.  We  include  reflexivity  in  PO  allowing  it  to 
be  commented  out  if  not  desired. 

Note:  A  lattice  is  a  partial  ordering  where  every  comparable  pair  of  items 
contain  both  a  least  upper  bound  (lub)  and  a  greatest  lower  bound  (gib),  which 
results  in  a  universal  upper  and  lower  bound  to  the  lattice. 

****************************************************************************** i 

pred  P  0  (  b  b :  Block-  >  B I  o  c  k )  { 

all  i  ,  j  ,  k :  (bb. Block  +  Block. bb) 

-  -  reflexive 

( 

i  -  >i  in  b  b 

)  && 

-  -  anti  symmet  r  i  c 

( 

(  (  i  -  >j  in  b  b )  &&  ( j  -  >i  in  b  b )  )  =>  (  i  =j  ) 

)  && 

--  transitive 

( 

(  (  i  -  >j  in  bb)  &&  ( j  -  >k  in  bb))  =>  (  i  -  >k  in  bb) 


} 

/  * **************************************************************************** * 

Overtime  an  item  of  information  may  no  longer  be  sensitive  and  its  sensitivity 
may  need  to  be  downgraded.  To  do  so  requires  violating  the  partial  ordering. 
Therefore  the  notion  of  a  Trusted  Subject  is  introduced.  A  Trusted  Subject  is 
a  Subject  (ie.  process)  that  has  undergone  rigorous  analysis  and  is  trusted  not 
to  downgrade  information  other  than  the  information  it  is  intended  to 
downgrade. 

******************************************************************************  j 

sig  Trusted  Subj  ect  extends  Subject  {} 


/  * **************************************************************************** * 
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A  Trusted  Subject  is  allowed  to  violate  the  partial  ordering  but  it  is  not 
required  to  violate  the  partial  ordering.  Therefore,  there  may  be  flows  in  the 

System  that  are  the  result  of  the  Trusted  Subjects  and  violate  the  partial 

ordering.  The  problem  here  is  that  we  do  not  really  have  a  way  of  identifying 
which  Subject,  trusted  or  otherwise,  caused  a  flow  in  bb,  after  all  the 
matrices  are  intended  to  be  orthogonal.  However,  the  reverse  may  be  possible. 
We  can  identify  the  flows  in  s  r  _  f I o  w  and  require  any  flow  that  upsets  the 

partial  ordering  in  bb  to  be  a  trusted  subject.  However,  this  also  requires  us 

to  identify  the  partial  ordering. 

****************************************************************************** i 

pr  ed  T P 0 (  sys :  Syst  em)  { 

let  Nontrusted_Subs_i  n_SR  =  domjsys.  sr_fl  ow]  -  Trusted_Subj  ect, 

NontrustedBI  ockFI  ow  =  {  bl,  b  2 :  Block  ,  m:  Mode 

( 

some  sub:  Nontrusted_Subs_i  n_SR,  r:  Resource 

( 

--  sub  is  a  non-trusted  subject  in  the  subject  part  of  s  r  _  f  I  o  w 
--  when  combined  with  some  resource  and 

--  and  the  mode  of  Nontrusted_BI  ock_FI  ow  is  also  in  s  r  _  f  I  o  w 
(sub  -  >  r  ->  m)  in  sys.  srfl  ow  and 

--  and  the  corresponding  blocks  of  that  subject  and  resource 
--  comprises  the  blocks  of  Nontrusted_BI  ock_FI  ow 
bl  =  sub.master  and  b2  =  r.master 


} 

--  The  transitive  closure  of 

--  the  intersection  of  the  Nontrusted_BI  ock_FI  ow  and  bb.flow 
-  -  with  the  Mode  r  e  mo  ved 
--  should  be  a  partial  ordering 

P  0  [  ''t  (  NontrustedBI  ockFI  ow  &  s  y  s .  b  b .  f  I  o  w)  .  Mod  e )  ] 

} 

/  * **************************************************************************** * 

A  secure  system  is  a  system  that  is  a  trusted  partial  ordering  where  only  flows 
in  by  both  matrices  ( s  r  _  f  I  o  w  and  bb.flow)  are  allowed. 

****************************************************************************** i 
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pred  Securef  sys:  System) 

{ 

T  P  0 [ sys]  && 

all  sub:  Subject,  res:  Resource,  mod:  Mode 

( 

(sub  -  >  res  -  >  mod )  in  s  y  s .  MM 

=  > 


(sub  ->  res  ■>  mod)  in  sys. srfl  ow  && 
mod  In  sys.  bb.fl  ow[sub.  master][res.  master] 

) 

) 

} 

pred  show  ()  {} 
run  show 


r  u  n 

s  how  f  or  3 

but  exactly 

3 

B 1 

oc  k 

r  u  n 

s  how  f  or  4 

but  exactly 

4 

B 1 

oc  k 

r  u  n 

s  how  f  or  3 

but  exactly 

3 

B 1 

ock,  exactly  6 

Resource 

pred 

s  howPO  (  ) 

{  some 

sys: 

Syst 

em  |  PO[  sys.  bb. 

FLOWS]  } 

r  u  n 

s  howPO 

r  u  n 

s  howPO  for 

3  but 

e  x  a  c  1 1 

y 

3 

Block 

r  u  n 

s  howPO  for 

4  but 

e  x  a  c  1 1 

y 

4 

Block 

r  u  n 

s  howPO  for 

3  but 

e  x  a  c  1 1 

y 

3 

Block,  exactly 

6  Resource 

pred  showTPO  ()  {  some  sys:  System  |  T  P  0[  sys]  } 
run  showTPO 

run  showTPO  for  4  but  exactly  4  Block,  exactly  1  Trusted_Subj  ect 

pred  s  howSec  u  r  e(  )  { 

so  me  sys:  System  |  Secure!  sys] 

} 

run  Secure 
run  showSecure 

run  showSecure  for  4  but  exactly  4  Block,  exactly  1  TrustedSubj  ect 
run  showSecure  for  4  but  exactly  4  Block,  exactly  0  TrustedSubj  ect 
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APPENDIX  B:  SEPARATION  KERNEL  INIT  FTLS  IN  ALLOY 


z  * **************************************************************************** * 

A  Least  Privilege  Model  for  Static  Separation  Kernels 
from  T. Levin,  C. Irvine,  T. Nguyen,  Cl  SR  Tech  Report  NPS-  CS-  05  -  003 
October  2004 

(references  to  the  Tables  in  the  paper) 

Least  Privilege  Separation  Kernel  Interface 
working  note  Version  0.6 
12  February  2007 

****************************************************************************** i 

module  sepkernel  _i  ni  t 

--  library  containing  the  domfunction 
open  ut i I / 1  er  nar  y  as  tern 

--  For  state  transitions 

open  ut i I / sequence! Transi  t i  on]  as  set_up_seq 


/  * **************************************************************************** * 

The  pre  milinary  interface  uses  parameters  such  as  resourcejd  and  parti  ti  on_i  d 
to  the  interface  functions.  In  order  to  conform  as  much  as  possible  to  the 
interace  we  have  added  these  to  the  to  Resource  and  Block.  The  Alloy  Analyzer 
will  place  an  integer  identifier  for  each  Resource,  Block,  etc.  that  it 
created  in  a  model.  Therefore,  adding  the  Resourcel  D  and  PartitionJD 
constructs  may  not  be  entirely  necessary,  but  creates  for  a  stronger  mapping. 

disj  is  a  native  Alloy  command  meaning  disjoint.  It  used  here  to  require  two 
elements  to  be  distinct. 

****************************************************************************** i 

-  -  Unique  Resource  identifier 
s  i  g  Resourcel  D  { } 

--  Every  resource  has  a  unique  ID 
fact 
{ 
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all  r 1 ,  r  2 :  Resource 


d  i  s  j  [  r  1 ,  r  2  ]  =>  di  sj  [  rl.  resourcei  d,  r2.  resourcei  d] 

} 


--  garuntees  no  resource_i  d1  s  that  do  no  participate  in  the  universe 
fact 
{ 

ResourceJD  in  Resource.  resource_i  d 

} 


--  Retrieve  the  corresponding  Resource 
--  This  function  is  not  currently  used 
fun  i  d_to_resource  (i:  Res ou r c e_ I  D) :  set  Resource 
{ 

{ 

r :  Resource  |  r.  resource_i  d  =  i 

} 

} 


--  Unique  Block  identifier 
sig  Parti  ti  on_l  D  {} 

--  Every  block  has  a  unique  ID 
fact 
{ 

all  b  1 ,  b2:  Block 

d  i  s  j  [  b 1 ,  b  2  ]  =>  di  sj  [  bl.  parti  ti  on_i  d,  b2.  parti  ti  on_i  d] 

} 

--  garuntees  no  pari  ti  on_i  d1  s  that  do  no  participate 
fact 
{ 

Parti  ti  on_l  D  in  Block,  partitionjd 

} 

--  Retrieve  the  corresponding  Block 
--  This  function  is  not  currently  used 
fun  i  d_to_bl  ock  (i:  Parti  ti  on_l  D)  :  set  Block 
{ 

{ 

b:  Block  |  b. partitionjd  =  i 

} 
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/  * **************************************************************************** * 


The  information  in  computer  systems  is  often  thought  of  generi  cal  I  y  as 
resources.  The  flow  of  information  is  then  described  as  a  matrix  of  what 
resource  is  allowed  to  read  and/or  write  to  another  resource.  This  is 
referred  to  as  an  access  matrix.  A  resource  is  anything  in  the  systemwe  wish 
to  consider,  be  it  a  file,  a  process,  a  user,  a  program,  fireware,  etc.  In 
Alloy  a  3-tuple  or  3  item  relation  can  be  used  to  indicated  the  access  matrix 
like  so,  Resource  ->  Resource  ->  Mode  The  'abstract'  keyword  below  indicates 
that  an  item  called  Mode  should  not  be  created  in  the  model.  The  'extends'  and 
'abstract'  keywords  are  analogous  to  object  oriented  programming  with  a 
heirarchy  of  parent  and  child  classes.  The  'one'  keyword  means  one  and  only 
one  item  called  RD  and  one  and  only  one  item  called  WT  should  be  the  mo  del. 

****************************************************************************** i 

-  -  R  in  the  paper 
s i  g  Resource 
{ 

--  Every  Resource  belongs  to  exactly  one  Block,  no  more,  no  less 
master:  one  Block, 

--  Added  to  conformto  the  interface 
resource_i  d:  one  Resourcel  D 

} 


-  -  access  rights  type,  F  in  the  paper 
abstract  sig  Mode  {} 

--  read  and  write  in  the  Paper 
one  sig  RD,  WT  extends  Mode  {} 


/  * **************************************************************************** * 

A  separation  kernel  partitions  all  the  resources.  The  separation  kernel  is 
simplistic  in  that  it  only  provides  the  isolation  of  resources  into  partitions 
which  we  will  call  Blocks.  In  the  systemevery  Resource  will  be  assigned 
exactly  one  and  only  one  Block,  thus  the  Blocks  represent  equivalence  classes 
of  Resources.  Our  separation  kernel  will  be  static,  therefore  there  will  be 
no  reassigning  of  Resources  to  different  Blocks  once  the  kernel  is  running  and 
it  will  not  make  sense  to  have  empty  Blocks.  It  is  not  useful  to  have  all 
resources  partitioned  into  a  single  Block  so  that  case  may  be  explicitly 
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excluded  from  the  model  in  order  to  make  it  mo  re  interesting 


****************************************************************************** i 

-  -  B  in  the  paper 
s  i  g  Block 
{ 

--  Added  to  conformto  the  interface 
parti  ti  on_i  d:  Partition  ID 

} 

--  each  block  has  at  least  one  resource,  no  empty  blocks 

{ 

so  me  r;  Resource  |  r.master  =  this 

} 


--  a  minimally  useful  kernel,  this  fact  may  be  commented  out 
--fact  {  #B I  o c  k  >  1  } 


/  * **************************************************************************** * 

The  system  will  contain  two  ma trices.  One  to  represent  the  flow  of  information 
between  blocks  and  one  for  the  flow  of  information  between  resources.  The  two 
matrices  are  intended  to  orthogonal,  that  is,  there  may  be  flows  allowed  in  one 
that  are  not  allowed  in  the  other.  We  will  be  interested  in  taking  the  partial 
ordering  and  the  trusted  partial  ordering  of  the  block  flow  matrix.  To  help 
with  the  trusted  partial  ordering  we  create  the  structure  below. 

We  can  consider  a  read  originating  from  BlockA  to  BlockB  to  be  the  same  as  a 
write  originating  from  BlockB  to  BlockA  in  terms  of  information  flow.  We  can 
simplify  either  statement  by  saying  information  has  flowed  from  BlockB  to 
Bl  o c  k A . 

Alloy  has  a  built  in  command  A  (carrot)  for  constructing  transitive  closures. 
The  transitive  closure  is  useful  for  seeing  all  blocks  that  information  can 
eventually  flow  into. 

******************************************************************************  j 

--  Bl  oc  k- To- Bl  oc  k  Flow  Matrix,  Table  1 
s i  g  BB{ 

flow:  Block  -  >  Block  -  >  Mode, 

--  those  are  secondary,  derived  fromthe  flow 
basi  c_fl  ow:  Block  -  >  Block, 
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FLOWS: 


Block  -  >  Block 


} 

{ 

•  -  definition  of  basic  flow 
basi c_fl ow  = 

{ 


a ,  b  Block 

WT  in  f  I  ow[  a]  [  b]  or 
RD  in  f  I  ow[  b]  [  a] 


FLOWS  is  a  transitive  closure  of  basi  c_f  I  ow 
F  L  OWS  =  A  basi  c_fl  ow 

These  two  are  for  better  visualizing  and  more  interesting  models 

block  always  can  access  itself  with  Read/Write 
all  b:  Block  |  #b .  (  b .  f  I  o  w)  =  #Mod  e 

each  access  mode  is  represented  at  least  once  in  the  elements  of  flow 
RD  in  Block. (Block. flow) 

WT  in  Block. (Block. flow) 


/  * **************************************************************************** * 

The  word  subject  and  object  are  typically  used  to  indicate  which  resource  is 
the  active  entity  performing  the  read  and/or  write  on  another  passive  resource. 
In  our  model  we  use  the  Subject  terminology  and  we  allow  one  Subject  to 
operate  on  another  Subject  (ie.  one  process  communicating  to  another  process). 
We  drop  the  Object  nomenclature  and  simply  refer  to  a  Subject  accessing  a 
Resource  (which  may  be  another  Subject). 

****************************************************************************** i 

s  i  g  Subject  extends  Resource  { } 


/  * **************************************************************************** * 

Memory  Segments  are  resources,  but  Subjects  are  not  Memory  Segments.  Therefore 
subjects  and  Memory  Segments  partition  Resources.  Memory  Segments  will  be 
assigned  to  each  ring  of  a  Process,  creat  e_memory_obj  and  open_memory_obj  will 
need  to  ensure  memory  segments  exist  in  a  strict  hierarchy.  That  is  a  memory 
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segment  will  have  no  more  than  one  parent  and  there  is  not  looping  in  the 
hi  e r  a r  c  h y . 

****************************************************************************** i 

--  A  Memory_Segment  is  a  Resource  and  it  has  zero  or  more  chiidern  that  are 
-  -  also  Memory  Segment  s 
sig  Me  mo  r  y_  S  eg  me  n  t  extends  Resource 
{ 

chiidern:  set  Me  mo  r  y  _  Seg  me  n  t 

} 

{ 

strongl  y  _  h  i  erarchi  cal  [thi  s] 

} 


-■  No  looping,  and  no  more  than  one  parent 
pred  strongl  y_hi  erarchi  cal  (m:  Memory_Segment ) 
{ 


let  child  =  {  x,  y:  Memory_Segment  |  y  in  x. chiidern  }, 
descendants  =  ''child 

■ ■  no  loops 

--  a  memory  segment  is  not  a  descendant  of  itself 
(  not  (min  m.  descendants)  && 

-  -  no  sharing 

--  a  memory  segment  has  only  one  parent 
--  no  two  parents  have  the  same  child 
(all  disj  ml,  m2:  Me  mo  r  y  _  Seg  me  n  t 

no  (  ml .  c  h  i  I  d e r  n  &  m2 .  c  h  i  I  d e r  n )  ) 


} 

/  * **************************************************************************** * 

Our  system  is  really  rather  simple.  It  is  two  access  matrices.  One  is  the 
block  flow  (  bb)  and  the  other  the  least  privilege  matrix  ( s  r  _  f  I  o  w)  which 
constrains  the  block  flow  (bb).  Later,  we  will  define  a  secure  system  to  be  a 
systemthat  only  allows  flows  that  are  permitted  by  both  matrices.  Technically 
s  r  _  f  I  o  w  is  not  required  to  be  a  subset  of  bb.  That  is,  it  may  allow  flows  that 
are  prohibited  by  bb,  however,  in  a  secure  system  those  flows  would  never  be 
realized,  because  what  is  allowed  is  only  the  intersection  of  the  two  matrices. 
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A  Block  may  contain  any  combination  of  Subjects  and  Resources.  Therefore,  the 
Block  nomenclature  is  devoid  of  the  Subject  and  Resource  distinction.  In 
order  to  better  visualize  and  talk  about  the  flow  of  information  only  Subjects 
are  allowed  to  read  and/or  write.  That  is  Resources  that  are  not  Subjects 
should  never  initiate  a  flow. 

Of  course  we  are  only  interested  in  Resources  and  Blocks  that  are  inside  of  our 
System.  Sense  all  Resources  belong  to  a  Block,  Alloy  will  not  produce 
Resources  or  Blocks  that  have  nothing  to  do  with  each  other.  In  like  manner  we 
need  to  instruct  Alloy  that  every  block  participates  in  the  Systemto  prevent 
Alloy  from  producing  models  with  Resources  and  Blocks  that  are  outside  of  the 
System. 

MM  should  be  orthogonal  to  SR  and  BB,  that  is  SR/BB  is  the  policy  of  what  is 
allowed,  and  MM  is  what  the  program  wants  to  do.  The  security  predicate  will 
say  that  a  secure  system  allows  only  the  p r og r a m  a c t i  o n s  that  conformto  the 
pol  i  cy. 

It  is  important  to  note  that  information  is  not  required  to  flow  into  or  out  of 
a  Block.  However,  a  completely  isolated  Block  would  not  be  useful. 

****************************************************************************** i 

s i  g  System  { 

resources:  set  Resource, 

bb:  BB, 

s r _ f  I  ow:  Subj  ect  -  resources  -  > Mo d e , 

MM:  Subject  ->  Resource  ->  Mode 

--  This  a  runtime  extension  of  the  model. 

--  RM:  resources  ->  Me  mo  r  y  _  Se  g  me  n  t 

} 

{ 

--  Every  Block  participates  in  the  System. 

--  We  start  with  an  empty  matrix  and  then  we  add  blocks 

Block  in  Bl  ock.  (  (  bb.  fl  ow)  .  Mode)  +  (  (  bb.  fl  ow)  .  Mode)  .  Bl  ock 

--  s  r  _  f  I  o  w  is  non  empty 
s  o  me  s  r  flow 


I* 

&& 

--  This  constraint  is  only  to  create  interesting  models.  It  is  recommend  to 
--  comment  out  this  section  to  study  the  model  the  way  it  was  intended. 
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--  A  completely  isolated  Block  is  not  useful  therefore: 

--  Every  block, 
all  b  1 :  blocks 

--  has  so  me  other  block, 
so  me  b  2 :  Block 

--  that  is  not  itself, 
d i  s  j  [ b 1 ,  b  2 ]  && 

( 

■  ■  which  it  neither  f  I  o  ws  into, 
b2  in  bl.  f  I  ow  or 

■  -  nor  out  of . 
b2  in  f  I  ow.  bl 

) 

*1 

} 

/  * **************************************************************************** * 

We  are  interested  with  a  traditional  confidentiality  policy  between  the  Blocks 
that  prohibits  reading  up  or  writing  down.  The  separation  kernel  itself  only 
isolates  the  Blocks  and  regulates  the  flow  between  them,  but  is  devoid  of 
semantics  labeling  one  Block  greater  than  another. 

However,  we  can  define  a  predicate  that  will  require  the  Blocks  to  be 
partitioned  in  such  a  way  that  information  is  not  allowed  to  flow  circularly. 
That  is  if  information  leaves  BlockA,  there  is  no  transitive  closure  of  the 
flows  that  will  lead  back  to  BlockA.  It  is  important  to  note  that  any  two 
Blocks  are  not  required  to  be  related.  For  example,  Bl  ockA-  >BI  ockC, 

Bl  ockB-  >BI  ockC,  but  there  is  no  flow  between  BlockA  and  BlockB  and  no 
indication  if  one  is  greater  than  the  other.  Therefore  such  a  non-circular 
flow  of  information  is  technically  considered  a  partial  ordering  but  not  a 
total  ordering.  That  is,  not  all  the  items  in  the  set  are  comparable. 

Mathematically  a  partial  ordering  (  PO)  is  defined  as  a  relation  over  a  set  that 
is  transitive  and  antisymmetric.  Antisymmetric  means  there  is  no  circularity 
in  the  relation.  Many  authors  extend  a  partial  ordering  to  include  reflexivity 
which  means  every  item  in  the  set  is  comparable  to  itselfs.  In  our  situation 
this  may  or  may  not  be  the  case.  We  include  reflexivity  in  PO  allowing  it  to 
be  co mme nted  out  if  not  desired. 

Note:  A  lattice  is  a  partial  ordering  where  every  comparable  pair  of  items 
contain  both  a  least  upper  bound  (lub)  and  a  greatest  lower  bound  (gib),  which 
results  in  a  universal  upper  and  lower  bound  to  the  lattice. 
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******************************************************************************  I 


pred  P  0  (  b  b :  Block-  >  B I  o  c  k )  { 

all  i  ,  j  ,  k :  (bb. Block  +  Block. bb) 

-  -  reflexive 

( 

i  -  >1  in  b  b 

)  && 

-  -  anti  s  y  mme  trie 

( 

{ ( i  -  >j  in  b  b )  &&  ( j  -  >i  in  b  b )  )  =>  ( i  =j  ) 

)  && 

--  transitive 

( 

( ( i  -  >j  in  bb)  &&  ( j  -  >k  in  bb))  =>  ( i  -  >k  in  bb) 


} 

/  * **************************************************************************** * 

Overtime  an  item  of  information  may  no  longer  be  sensitive  and  its  sensitivity 
may  need  to  be  downgraded.  To  do  so  requires  violating  the  partial  ordering. 
Therefore  the  notion  of  a  Trusted  Subject  is  introduced.  A  Trusted  Subject  is 
a  Subject  (ie.  process)  that  has  undergone  rigorous  analysis  and  is  trusted  not 
to  downgrade  information  other  than  the  information  it  is  intended  to 
downgrade. 

******************************************************************************  j 

sig  Trusted  Subj  ect  extends  Subject  {} 


/  * **************************************************************************** * 

A  Trusted  Subject  is  allowed  to  violate  the  partial  ordering  but  it  is  not 
required  to  violate  the  partial  ordering.  Therefore,  there  may  be  flows  in  the 
Systemthat  are  the  result  of  the  Trusted  Subjects  and  violate  the  partial 
ordering.  The  problem  here  is  that  we  do  not  really  have  a  way  of  identifying 
which  Subject,  trusted  or  otherwise,  caused  a  flow  in  bb,  after  all  the 
matrices  are  intended  to  be  orthogonal.  However,  the  reverse  may  be  possible. 
We  can  identify  the  flows  in  s  r  _  f I  o  w  and  require  any  flow  that  upsets  the 
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partial  ordering  in  bb  to  be  a  trusted  subject.  However,  this  also  requires  us 
to  identify  the  partial  ordering. 

****************************************************************************** i 

pr  ed  T P 0 (  sys :  System)  { 

let  Nontrusted_Subs_i  n_SR  =  domjsys.  srfl  ow]  -  Trusted_Subj  ect, 

Nontrusted  BI  ock  FI  ow  =  {  bl,  b 2 :  Block  ,  m:  Mode 

( 

some  sub:  Nontrusted_Subs_i  n_SR,  r:  Resource  | 

( 

--  sub  is  a  non-trusted  subject  in  the  subject  part  of  s  r  _  f  I  o  w 
--  when  combined  with  some  resource  and 

--  and  the  mode  of  Nontrusted_BI  ock_FI  ow  is  also  in  s  r  _  f  I  o  w 
(sub  -  >  r  ->  m)  in  sys.  sr_fl  ow  and 

--  and  the  corresponding  blocks  of  that  subject  and  resource 
--  comprises  the  blocks  of  Nontrusted_BI  ock_FI  ow 
bl  =  sub.master  and  b2  =  r.master 

) 

) 

} 

--  The  transitive  closure  of 

--  the  intersection  of  the  Nontrusted_BI  ock_FI  ow  and  bb.flow 
-  -  wi  t  h  the  Mode  r  emoved 
--  should  be  a  partial  ordering 

P  0  [  (  NontrustedBI  ockFI  ow  &  s  y  s .  b  b .  f  I  o  w)  .  Mod  e )  ] 

} 

/  * **************************************************************************** * 

A  secure  system  is  a  system  that  is  a  trusted  partial  ordering  where  only  flows 
in  by  both  matrices  ( s  r  _  f  I  o  w  and  bb.flow)  are  allowed. 

******************************************************************************  j 


pred  Securef  sys:  System) 

{ 

T  P  0 [ sys]  && 

all  sub:  Subject,  res:  Resource,  mod:  Mode 

( 

(sub  -  >  res  -  >  mod )  in  s  ys .  MM 
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(sub  ->  res  ->  mod)  in  sys. srfl  ow  && 
mod  in  sys.  bb.fl  ow[sub.  master][res.  master] 


} 

/  * **************************************************************************** * 

The  above  defines  a  secure  system  and  what  it  means  to  be  in  a  secure  state. 

In  the  strictest  sense  the  concept  of  transitioning  fromone  state  to  another 
does  not  exist  in  this  definition  because  the  system  is  static  and  either  the 
system  is  secure  or  it  isn't.  The  matrices  do  not  change  once  brought  into 
exi  st  ence. 

This  model  represents  the  initialization  phase  of  the  system.  We  start  with 
an  empty  system  (no  matrices  with  no  allowed  flows)  and  end  with  the  matrices 
that  conformto  the  security  predicate. 

In  order  to  visualize  transitions  operation  we  create  a  Transition  signature 
that  includes  the  current  system  along  the  last  command  execute,  the 
corresponding  arguments,  and  the  last  error  message. 

We  create  stubs  for  many  of  the  init  commands.  They  may  not  effect  our 
definition  of  security  so  for  now  we  leave  them  out  of  the  model. 

******************************************************************************  j 

--  List  of  commands  in  the  preliminary  interface, 
abstract  s  i  g  Co  mma  n  d  { } 
one  sig  no_op_com, 

set_parti  ti  on  fl  ows_com, 
set_resource_f  I  ows_com, 
create_parti  ti  on_com, 
create_process_com, 
create_memory_obj  e  c  t  _  c  o  m, 
open_memory_obj  e  c  t  _  c  o  m, 
cl  ose_memory_obj  ect_com 
extends  Command  {} 

--  An  error  for  each  co mma n d 
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abstract  s i  g  Error  {  } 
one  s i  g  n o _ e r  r , 

set_parti  ti  o  n  _  f  I  o  ws  _  e  r  r , 
set_resource_f  I  o  ws  _  e  r  r , 
create_parti  ti  o  n  _  e  r  r , 
create_process_err, 
create_memory_obj  e  c  t  _  e  r  r , 
open_memory_obj  e  c  t  _  e  r  r , 
cl  ose_memory_obj  e  c  t  _  e  r  r 
extends  Error  {} 


sig  Transition 

{ 

errormessage:  Error, 

I  a  s  t  _  c  o  mma  n  d :  Co  mma  n  d , 
arguments:  set  u  n  i  v , 

s  y s :  System 

} 


/  * **************************************************************************** * 

Parameters  for  some  of  the  commands. 

****************************************************************************** i 

-  -  Used  by  setparti  ti  on_fl  ows 
sig  Parti  t  i  o  n  _  F I  o  w_  Vector 
{ 

v:  Parti  ti  on_l  D  ->  Parti  ti  onl  D  ->  Mode 

} 

{ 

s  o  me  v 

} 


-  -  Used  by  set_resource_f  I  ows 
sig  Resour  ce  Vect  or 
{ 

v:  Resource  l  D  ->  Resource^!  D  ->  Mode 


} 

{ 


s  o  me  v 

} 
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--  Used  by  create_parti  ti  on 
sig  Parti  ti  on_Resource_Vector 
{ 

v :  PartitionJD  -  >  ResourceJD 

} 

{ 

s  o  me  v 

} 


/  * **************************************************************************** * 

Create  Process,  create_mem_obj  ,  o  p  e  n  _  me  m_  o  b  j  all  take  handles  as  input. 

****************************************************************************** i 

sig  Handle 

{ 

seg:  one  Me  mo r y_ Seg me n t , 
mod:  Mode 


/  * **************************************************************************** * 

We  define  a  process  here  because  this  is  the  first  time  it  is  introduced  to  the 
model.  It  has  a  time  slice  and  set  of  memory  segments,  but  for  now  we  leave 
those  out  of  the  model. 

******************************************************************************  j 

sig  Process  extends  Subject 

{ 


i  n  g  1 

one 

Me  mo  r  y  _  Se  g  me  n  t 

i  n  g  2 : 

one 

Me  mo  r  y  _  Se  g  me  n  t 

i  n  g  3 : 

one 

Me  mo  r  y  _  Se  g  me  n  t 

--  Local  Descriptor  Table 
I  dt :  set  Handle 

} 

{ 

--  The  ring  handles  point  to  distinct  memory 
disjjringl,  r  i  n  g  2 ,  r  i  n  g  3  ] 
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/  * **************************************************************************** * 


The  first  tranistion  in  the  program  begins  empty,  with  no  commands,  arguments, 
or  error  messages.  The  matrices  are  entirely  empty. 

****************************************************************************** i 

fact  i  ni  t_set_up_seq{ 

let  t  =  Seq::set_up_seq/first[] 


no. 

_er 

r 

= 

t . 

error 

_  me  s  s  a  g  e 

no. 

.OP 

_  c  o  m  = 

t . 

1  a  s  t  _ 

c  o  mma  n  d 

no 

t . 

a  r  g  u  me  n  t  s 

&& 

no 

t . 

sys. 

resources 

&& 

no 

t . 

sys. 

bb. 

f  i 

0  w 

&& 

no 

t . 

sys. 

s  r  _ 

f  1 

0  w 

&& 

no 

t . 

sys. 

MM 

} 


/  * **************************************************************************** * 

Every  transition  involves  a  command  in  the  interface  document.  As  the 
commands  are  executed  either  error  messages  are  generated  or  the  matrices  are 
filled  in.  The  ||  (or)  condition  separate  each  possible  command. 

****************************************************************************** i 

fact  t  rans_set  up 

{ 

--  This  is  for  mo  re  interesting  mo  dels 
-  -  set_up_seq/  al  I  Exi  s  t  No  Du  pi  i  c  a  t  e  s  [  ]  && 

--  For  all  seqence  indices  except  the  first  one 

all  sqidx:  Seq:  :  set_up_seq  /  i  nds[ )  -  set_up_seq/firstldx[] 

{ 


let  t  =  set_up_seq/Seq::at[  set_up_seq  /  prev[  sqi  dx]  ], 
t 1  =  set_up_seq/ Seq : : a t [ s q i  d x ] 


To  prevent  a  tranisition  that  is  the  same  command,  same  args, 
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--  same  error  and  same  system  from  occuring  next  to  each  other 
-  - di  sj  [ t 1 .  sys,  t .  sys]  && 


--  sequence  of  commands  (predicates)  separated  by  or 

some  s:  System,  p  v  e  c :  Parti  ti  on_FI  ow_  Vector  | 

{ 


setparti  ti  on_fl  ows[t.  sys,  s,  p  v  e  c ]  && 
Secure! s] 


t 1 

■  sys 

=  s 

&& 

t 1 

.  1  a  s  t  _  c  o  mma  n  d 

=  set_part  i  t  i  o n _ f 1  ows_com 

&& 

t 1 

.  a  r  g  u  me  n  t  s 

=  pvec 

&& 

t 1 

.  e  r  r  o  r  _  me  s  s  a  g  e 

=  no_er  r 

else  ( 

t 1 .  sys 

t 1  .  I  a  s  t  _  c  o  mma  n  d 
t 1  .  ar  gument  s 
t1  .  error_message 


t .  sys  && 

setparti  t  i  on_fl  ows_com  && 
p  v  e  c  && 

setpart  i  ti  o  n  _  f  I  o  ws  _  e  r  r 


}  -  -  s  o  me 


some  s:  System,  rvec:  Resource_Vect  or 

{ 


set_resource_fl  ows[t.  sys,  s,  rvec]  && 
Secure] s ] 


t 1 .  sys 

t 1  .  I  a  s  t  _  c  o  mma  n  d 
t 1  .  ar  gument  s 
t1  .  er  ror_message 

) 

else  ( 

t 1 .  sys 

t 1  .  I  a  s  t  _  c  o  mma  n  d 
t 1  .  a  r  g  u  me  n  t  s 
t1  .  er  ror  message 


s  && 
set_resource_fl  ows_com  && 
rvec  && 
no  err 


t .  sys  && 
set_resource_fl  ows_com  && 
rvec  && 
set  resource  f I  ows  err 
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}  -  -  s  o  me 


some  s:  System,  p  v  e  c :  Parti  ti  on_Resource_Vector 

{ 


create  parti ti  on[t. sys,  s,  p v e c ]  && 
Secure! s] 


=  >  ( 


t 1 

■  sys 

=  s 

&& 

t 1 

.  1  a  s  t  _  c  o  mma  n  d 

=  createparti ti  on_com 

&& 

t 1 

.  ar  gument  s 

=  pvec 

&& 

t 1 

.  e  r  r  o  r  _  me  s  s  a  g  e 

=  n  o  _  e  r  r 

else  ( 


t 1 

■  sys 

=  t .  sys 

&& 

t 1 

.  1  a  s  t  _  c  o  mma  n  d 

=  create_parti ti on_com 

&& 

t 1 

.  ar  gument  s 

=  pvec 

&& 

t 1 

.  er  ror  message 

=  createparti ti on_err 

}  -  -  s  o  me 


some  s:  System,  processjd:  ResourceJD,  p  a  r  t  _  i  d :  Parti  ti  on_l  D, 
hdl,  h  d  2 ,  h  d  3 :  Handle 


{ 

disjlhdl,  h d 2 ,  h d 3 ]  && 


create_process[t.  sys,  s,  processjd,  parti  d ,  hdl,  h  d  2 ,  h  d  3  ]  && 
Secure! s] 


t 1 .  sys 

t 1  .  I  a  s  t  _  c  o  mma  n  d 
t 1  .  a  r  g  u  me  n  t  s 

t'.error_  message  = 

) 

else  ( 

t 1 .  sys 


s  && 

c  r  eat  e_  pr  oc  es  s_c  om  && 
p  r  o  c  e  s  s  _ i  d  +  part _i  d  + 
hdl  +  h  d  2  +  h  d  3  && 

n  o  _  e  r  r 

t .  s ys  && 
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t 1  .  I  a  s  t  _  c  o  mma  n  d  =  create_process_com  && 
t1  .  arguments  =  processjd  +  partjd  + 

hdl  +  h  d  2  +  h  d  3  && 

t 1  .  e  r  r  o  r  _ message  =  create_process_err 


}  -  -  s  o  me 


some  s:  System,  parenthandl  e:  Handle,  parti  d :  Parti  ti  on!  D 

{ 


create  memory  obi  ect[t.  sys,  s,  parent  handle,  part  id]  && 


Secure] s ] 

) 

=  >  ( 

t 1 .  sys 

t 1  .  I  a  s  t  _  c  o  mma  n  d 
t1  .  arguments 
t'.error_  message  = 

) 

else  ( 

t 1 .  sys 

t 1  .  I  a  s  t  _  c  o  mma  n  d 
t1  .  arguments 
t 1  .  e  r  r  o  r  _  me  s  s  a  g  e  = 

) 

}  -  -  s  o  me 


s 

&& 

c  r  eat  e_  memo r  y_ 

obj  e c  t  _ c o m 

&& 

parent_handl  e 

+  pa  r  t  _  i  d 

&& 

no  err 

t .  s ys  && 

c  r  ea  t  e_  me  mo  r  y  _  o  bj  ec  t  _  c  o  m  && 
parent_handle  +  p  a  r  t  _  i  d  && 
create_memory_obj  e  c  t  _  e  r  r 


some  s:  System,  pa  r  e  n  t  _  h  a  n  d  I  e ,  obj  handl  e:  Handle,  mod:  Mode 

{ 


open_memory_obj  ect[t.  sys,  s,  parent_handle,  obj  handl  e,  mod]  && 
Secure] s] 


t 1 .  sys 

t 1  .  I  a  s  t  _  c  o  mma  n  d 
t 1  .  ar  gument  s 
t1  .  error_message 

) 

else  ( 

t 1 .  sys 


s  && 

open_memory_obj  ect_com  && 

parent_handl  e  +  obj  _handl  e  +  mod  && 
no  err 


t .  sys 


&& 
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t 1  .  I  a  s  t  _  c  o  mma  n  d  =  open_memory_obj  ect_com  && 

t1  .  arguments  =  pa  r  e  n  t  _  h  a  n  d  I  e  +  obj  _handl  e  +  mod  && 

t 1  .  e  r  r  o  r  _  message  =  open_memory_obj  ect_err 


}  -  -  s  o  me 


some  s:  System,  obj  _handl  e:  Handle 

{ 


cl  ose_memory_obj  ect[t.  sys,  s,  obj  _  handle]  && 
Secure! s] 


=  > 


t 1 .  sys 

t 1  .  I  a  s  t  _  c  o  mma  n  d 
t 1  .  a  r  g  u  me  n  t  s 
t 1  .  e  r  r  o  r  _  me  s  s  a  g  e 


s  && 

cl  ose_memory_obj  ect_com  && 
o  bj  _  h  a  n  d  I  e  && 

no  err 


else  ( 


t 1 .  sys 

=  t .  s ys 

&& 

t 1  .  1  a  s  t  _  c  o  mma  n  d 

=  cl  ose_memory_obj  ect_com 

&& 

t 1  .  ar  gument  s 

=  o  bj  _  h  a  n  d  1  e 

&& 

t1  .  error_message 

=  cl  ose_memory_obj  ect_err 

}  -  -  s  o  me 


}- -  al  I 


/  * **************************************************************************** * 
There  is  one  predicate  here  for  each  command. 

****************************************************************************** i 

pred  setparti  ti  on_fl  owsfsys,  sys1:  System,  p  v  e  c :  Parti  ti  on_FI  ow_Vector) 

{ 

let  new_  bb  = 

{ 

bl,  b  2 :  Block,  m:  Mode 
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(bl.partitionjd  ■>  b2.  parti  ti  on_i  d  -  >  m)  in  pvec.v 

) 

} 

sys'.bb.flow  =  sys.bb.flow  +  new_bb  && 

sys'.srflow  =  sys.sr_flow  && 

sys'.MM  =  sys.MM  && 

sys1 .  resources  =  sys.  resources 


pred  set_resource_fl  owsfsys,  sys1:  System,  r  v  e  c :  Res  o  u  r  c  e_  Vec  t  o  r ) 

{ 

let  new_sr_fl  ow  = 

{ 

s :  Subject,  r :  Resource,  m:  Mode  | 

( 

(s.resourcejd  -  >  r.resourcejd  -  >  m)  in  rvec.v 


} 


sys1 

s  r  _ 

f  1  ow  = 

sys.  s  r 

_ f  1  o w  +  new_sr_fl  ow 

&& 

sys' 

bb 

=  sys. 

bb 

&& 

sys' 

MM 

=  sys. 

MM 

&& 

sys' 

,  resources 

=  sys. 

resources  + 

(  new_sr_fl  ow.  Mode)  .  Resource  /*  + 
Subj  ect.  (  new_sr_fl  ow.  Mode)  * / 


--  For  a  future  dynamic  extension  of  the  model 

--  pred  set_subj  _pri  vi  I  egesfsys,  sys1:  System,  p  v  e  c :  Pri  vi  I  ege_Vector)  {} 

pred  createparti  ti  on(  sys,  sys1:  System,  p  v  e  c :  Parti  ti  on_Resource_Vector) 

{ 

--  Every  resource  that  corresponds  to  the  resourcejd  in  the  vector 
--  belongs  to  the  systems  set  of  resources 
sys1.  resources  =  sys.  resources  + 

{r:  Resource  |  r.  resource_i  d  in  Parti  ti  on_l  D.  (  pvec.  v)  }  && 

--  all  the  old  blocks  are  in  the  new  system 
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--  all  the  added  blocks  are  in  the  new  system 

let  add_bl  ocks  =  {b:  Block  |  b.  parti  ti  on_i  d  in  (  pvec.  v)  .  Resourcel  D}, 

ol  d_bl  ocks  =  (  B I  oc  k .  (  ( s  y  s .  b  b .  f  I  o  w)  .  Mo  d  e )  +  (  ( sys.  bb.  f  I  ow)  .  Mode)  .  Bl 

new_bl  ocks  =  (  B I  oc  k .  (  ( s y s 1  .  b b .  f  I  o w)  .  Mod e )  +  (  (  s y s 1  .  b b .  f  I  o w)  .  Mod e )  . 


( ol  d_bl  ocks  +  add_bl  ocks)  in  new_  blocks 


--  everything  else  stays  the  same 
sys'  .  sr_fl  ow  =  sys.  sr_fl  ow  && 
s  y  s 1 .  MM  =  s  y  s .  MM 


pred  create_process(  sys,  sys1:  System, 

processi  d:  Resourcel  D,  parti  d :  Parti  ti  on_l  D, 
handlel,  h  a  n  d  I  e  2 ,  h  a  n  d  I  e  3 :  Handle) 

{ 

-  -  Assign  process_i  d  to  MM,  etc 

-  -  add  process 
s  o  me  p  r  o  c :  Process 

not  (  pr  oc  in  sys.  resources  )  && 

(  pr  oc  in  s  y s 1 .  r  es  ou  r  c  es  )  && 

proc.  resource_i  d  =  processjd  && 

proc.  master,  parti  ti on_i d  =  parti d  && 


-  -  ma  k  e  s  sure 

it  has  the 

right 

proc. 

r  i  n  g  1  = 

handl  el.  seg 

&& 

proc. 

r  i  n  g  2  = 

handl  e 2 .  seg 

&& 

proc. 

r  i  n  g  3  = 

handl  e 3 .  seg 

propert i  es 


pred  c  r  eat  e_  memor  y_o  bj  ec  t  ( s  y  s ,  sys1:  System, 

parent_obj  handl  e:  Handle, 
parti  d :  Parti  ti  on_l  D) 

{ 

s  o  me  child:  Me  mo  r  y_  S  eg  me  n  t 

{ 

child  in  pa r e n t _ o b j _ h a n d I  e .  s eg .  c h i I  d e r n  && 

parti  d  in  chi  I  d.  master,  parti  ti  on_i  d  && 


oc  k) , 
Bl  oc  k) 
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strongl  y_hi  erarchi  cal  [  parent_obj  handl  e.  seg]  && 
sys1  .  resources  =  sys.  resources  +  child 

} 

sys1. bb. flow  =  sys. bb. flow  && 
sys'  .  sr_fl  ow  =  sys.  sr_fl  ow  && 
s  y s 1 .  MM  =  s  y  s .  MM 

} 

pred  open_memory_obj  ectfsys,  sys1:  System, 

parent_obj  handl  e,  obj  _handl  e: 
md :  Mode) 

{ 

some  child:  parent_obj  _handl  e.  seg.  chi  I  dern 

{ 

child  in  obj  handl  e.  seg  && 
md  in  obj  _handl  e.  mod 

} 


sys1 

bb. 

flow  = 

sys. 

bb 

.flow 

&& 

sys' 

s  r  _ 

f  1  ow  = 

sys. 

s  r 

_  f  1  o  w 

&& 

sys' 

MM 

= 

sys. 

MM 

&& 

sys' 

,  resources 

=  sys. 

resources 

} 

pred  cl  ose_memory_obj  ectfsys,  sys1:  System, 

obj  handl  e:  Handle) 


sys' 

bb. 

flow  = 

sys. 

bb 

.flow 

&& 

sys' 

s  r  _ 

flow  = 

sys. 

s  r 

_  f  1  0  w 

&& 

sys' 

MM 

= 

sys. 

MM 

&& 

sys' 

,  resources 

=  sys. 

resources 

pred  show  ()  {} 
run  show 


--  no  transitions  outside  of  the  sequence 
fact  every_t  ransi  ti  o n _ i  n_sequence 
{ 


Handl  e , 
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Transition  in  set_up_seq/Seq:  :  el  ems[  ] 

} 

--  Without  this  constraint  sequences  are  created  different  transitions 
fact  exact  I  y_one_sequence 
{ 

one  Seq 

} 

assert  Sec  u  r  e  T  r a  ns 

{ 

all  t:  Transition  |  Secureft,  sys] 

} 

check  SecureTrans  for  3 

check  SecureTrans  for  3  but  exactly  1  Process 
check  SecureTrans  for  4 


assert  n o _ I o o p { 

no  m:  Me  mo  r  y  _  Seg  me  n  t  |  not  strongl  y_hi  erarchi  cal  [m] 

} 

check  nojoop  for  5  but  exactly  1  Seq,  exactly  1  Seqldx 
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APPENDIX  C:  SEPARATION  KERNEL  RUNTIME  FTLS  IN 

ALLOY 


z  * **************************************************************************** * 

A  Least  Privilege  Model  for  Static  Separation  Kernels 
from  T. Levin,  C.  Irvine,  T. Nguyen,  Cl  SR  Tech  Report  NPS-  CS-  05  -  003 
Oct  ober  2  0  0  4 

(references  to  the  Tables  in  the  paper) 

****************************************************************************** i 

module  sep_kernel_run_ti  me 

--  library  containing  the  domfunction 
open  ut i I / 1  er  nar  y  as  tern 

--  For  state  transitions 

open  uti I /sequence[Transi  ti  on]  as  runti  me_seq 


/  * **************************************************************************** * 

The  pre  milinary  interface  uses  parameters  such  as  resourcejd  and  parti  ti  on_i  d 
to  the  interface  functions.  In  order  to  conform  as  much  as  possible  to  the 
interace  we  have  added  these  to  the  to  Resource  and  Block.  The  Alloy  Analyzer 
will  place  an  integer  identifier  for  each  Resource,  Block,  etc.  that  it 
created  in  a  model.  Therefore,  adding  the  Resource!  D  and  PartitionJD 
constructs  may  not  be  entirely  necessary,  but  creates  for  a  stronger  mapping. 

disj  is  a  native  Alloy  command  meaning  disjoint.  It  used  here  to  require  two 
elements  to  be  distinct. 

****************************************************************************** i 

-  -  Unique  Resource  identifier 
s  i  g  Res  our  c  e _l  D  { } 

--  Every  resource  has  a  unique  ID 
fact 
{ 

all  r 1,  r2:  Resource  | 

d  i  s  j  t  r  1 ,  r  2  ]  =>  di  sj  [  rl.  resourcei  d,  r2.  resourcei  d] 

} 
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--  garuntees  no  resourcei  d1  s  that  do  no  participate  in  the  universe 
fact 
{ 

Resourcei  D  in  Resource,  resourcei d 

} 


--  Retrieve  the  corresponding  Resource 
--  This  function  is  not  currently  used 
fun  i  d_to_resource  (i:  Resourcei  D) :  set  Resource 
{ 

{ 

r:  Resource  I  r. resource  id  =  i 


--  Unique  Block  identifier 
sig  Parti  ti  on_l  D  {} 

--  Every  block  has  a  unique  ID 
fact 
{ 

all  b  1 ,  b  2 :  Block  | 

d  i  s  j  [  b 1 ,  b  2  ]  =>  di  sj  [  bl.  parti  ti  on_i  d,  b2.  parti  ti  on_i  d] 


-■  garuntees  no  par  i  t  i  on_i  d1  s  that  do  no  participate 
fact 
{ 

Parti  tionJD  in  Block,  parti  tionjd 

} 


--  Retrieve  the  corresponding  Block 
--  This  function  is  not  currently  used 
fun  i  d_to_bl  ock  (i:  Pa  r  t  i  t  i  o  n_  I  D)  :  set  Block 
{ 

{ 

b:  Block  |  b.  parti  ti  on_i  d  =  i 

} 


/  * **************************************************************************** * 
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The  information  in  computer  systems  is  often  thought  of  generi  cal  I  y  as 
resources.  The  flow  of  information  is  then  described  as  a  matrix  of  what 
resource  is  allowed  to  read  and/or  write  to  another  resource.  This  is 
referred  to  as  an  access  matrix.  A  resource  is  anything  in  the  systemwe  wish 
to  consider,  be  it  a  file,  a  process,  a  user,  a  program,  fireware,  etc.  In 
Alloy  a  3-tuple  or  3  item  relation  can  be  used  to  indicated  the  access  matrix 
like  so,  Resource  ->  Resource  ->  Mode  The  'abstract'  keyword  below  indicates 
that  an  item  called  Mode  should  not  be  created  in  the  model.  The  'extends'  and 
'abstract'  keywords  are  analogous  to  object  oriented  programming  with  a 
heirarchy  of  parent  and  child  classes.  The  'one'  keyword  means  one  and  only 
one  item  called  RD  and  one  and  only  one  item  called  WT  should  be  the  mo  del. 

****************************************************************************** i 

-  -  R  in  the  paper 
s i  g  Resource 
{ 

--  Every  Resource  belongs  to  exactly  one  Block,  no  more,  no  less 
master:  one  Block, 

--  Added  to  conformto  the  interface 
resource_i  d:  one  Resourcel  D 

} 


-  -  access  rights  type,  F  in  the  paper 
abst  ract  si  g  Mode  {} 

-  -  read  and  wr  i  t  e  in  the  Paper 
one  sig  RD,  WT  extends  Mode  {} 


/  * **************************************************************************** * 

A  separation  kernel  partitions  all  the  resources.  The  separation  kernel  is 
simplistic  in  that  it  only  provides  the  isolation  of  resources  into  partitions 
which  we  will  call  Blocks.  In  the  systemevery  Resource  will  be  assigned 
exactly  one  and  only  one  Block,  thus  the  Blocks  represent  equivalence  classes 
of  Resources.  Our  separation  kernel  will  be  static,  therefore  there  will  be 
no  reassigning  of  Resources  to  different  Blocks  once  the  kernel  is  running  and 
it  will  not  make  sense  to  have  empty  Blocks.  It  is  not  useful  to  have  all 
resources  partitioned  into  a  single  Block  so  that  case  may  be  explicitly 
excluded  from  the  model  in  order  to  make  it  mo  re  interesting. 

****************************************************************************** i 
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-  -  B  in  the  paper 
s  i  g  Block 
{ 

--  Added  to  conformto  the  interface 
parti  ti  on_i  d:  Partition  ID 

} 

--  each  block  has  at  least  one  resource,  no  empty  blocks 

{ 

so  me  r:  Resource  |  r.master  =  this 

} 


--  a  minimally  useful  kernel,  this  fact  may  be  commented  out 
fact  {  #  B I  o  c  k  >  1  } 


/  * **************************************************************************** * 

The  system  will  contain  two  ma trices.  One  to  represent  the  flow  of  information 
between  blocks  and  one  for  the  flow  of  information  between  resources.  The  two 
matrices  are  intended  to  orthogonal,  that  is,  there  may  be  flows  allowed  in  one 
that  are  not  allowed  in  the  other.  We  will  be  interested  in  taking  the  partial 
ordering  and  the  trusted  partial  ordering  of  the  block  flow  matrix.  To  help 
with  the  trusted  partial  ordering  we  create  the  structure  below. 

We  can  consider  a  read  originating  from  BlockA  to  BlockB  to  be  the  same  as  a 
write  originating  from  BlockB  to  BlockA  in  terms  of  information  flow.  We  can 
simplify  either  statement  by  saying  information  has  flowed  from  BlockB  to 
Bl  o c  k A . 

Alloy  has  a  built  in  command  A  (carrot)  for  constructing  transitive  closures. 
The  transitive  closure  is  useful  for  seeing  all  blocks  that  information  can 
eventually  flow  into. 

****************************************************************************** i 

--  B I  oc  k- To- Bl  oc  k  Flow  Matrix,  Table  1 
s  i  g  B  B  { 

flow:  Block  -  >  Block  -  >  Mode, 

--  those  are  secondary,  derived  fromthe  flow 
basi  c_fl  ow:  Block  -  >  Block, 

FLOWS:  Bl  ock  -  >  Bl  ock 


} 

{ 
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definition  of  basic  flow 
basi c_fl ow  = 

{ 

a ,  b  Block  | 

WT  in  f  I  ow[  a]  [  b]  or 
RD  in  f  I  ow[  b]  [  a] 


--  FLOWS  is  a  transitive  closure  of  basi  c_f  I  ow 
F  L  OWS  =  A  basi  c_fl  ow 

--  These  two  are  for  better  visualizing  and  more  interesting  models 

--  block  always  can  access  itself  with  Read/Write 
all  b:  Block  |  #b .  ( b .  f  I  o  w)  =  #Mod  e 

--  each  access  mode  is  represented  at  least  once  in  the  elements  of  flow 
RD  in  Block. (Block. flow) 

WT  in  Block. (Block. flow) 

} 


/  * **************************************************************************** * 

The  word  subject  and  object  are  typically  used  to  indicate  which  resource  is 
the  active  entity  performing  the  read  and/or  write  on  another  passive  resource. 
In  our  model  we  use  the  Subject  terminology  and  we  allow  one  Subject  to 
operate  on  another  Subject  (ie.  one  process  communicating  to  another  process). 
We  drop  the  Object  nomenclature  and  simply  refer  to  a  Subject  accessing  a 
Resource  (which  may  be  another  Subject). 

******************************************************************************  j 

s  i  g  Subject  extends  Resource  { } 


/  * **************************************************************************** * 

In  order  to  simplify  the  modeling  of  reading  and  writing  we  simply  declared  a 
memory  independent  of  resources.  We  leave  processes  and  handels  out  of  this 
model  . 

******************************************************************************  j 

s  i  g  Me  mo  r  y_  S  eg  me  n  t  {  } 
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/  * **************************************************************************** * 


Our  system  is  really  rather  simple.  It  is  two  access  matrices.  One  is  the 
block  flow  (  bb)  and  the  other  the  least  privilege  matrix  ( s  r  _  f  I  o  w)  which 
constrains  the  block  flow  (bb).  Later,  we  will  define  a  secure  system  to  be  a 
systemthat  only  allows  flows  that  are  permitted  by  both  matrices.  Technically 
s  r  _  f  I  o  w  is  not  required  to  be  a  subset  of  bb.  That  is,  it  may  allow  flows  that 
are  prohibited  by  bb,  however,  in  a  secure  systemthose  flows  would  never  be 
realized,  because  what  is  allowed  is  only  the  intersection  of  the  two  matrices. 

A  Block  may  contain  any  combination  of  Subjects  and  Resources.  Therefore,  the 
Block  nomenclature  is  devoid  of  the  Subject  and  Resource  distinction.  In 
order  to  better  visualize  and  talk  about  the  flow  of  information  only  Subjects 
are  allowed  to  read  and/or  write.  That  is  Resources  that  are  not  Subjects 
should  never  initiate  a  flow. 

Of  course  we  are  only  interested  in  Resources  and  Blocks  that  are  inside  of  our 
System.  Sense  all  Resources  belong  to  a  Block,  Alloy  will  not  produce 
Resources  or  Blocks  that  have  nothing  to  do  with  each  other.  In  like  manner  we 
need  to  instruct  Alloy  that  every  block  participates  in  the  Systemto  prevent 
Alloy  from  producing  models  with  Resources  and  Blocks  that  are  outside  of  the 
System. 

MM  should  be  orthogonal  to  SR  and  BB,  that  is  SR/BB  is  the  policy  of  what  is 
allowed,  and  MM  is  what  the  program  wants  to  do.  The  security  predicate  will 
say  that  a  secure  system  allows  only  the  pr ogr am  act i  ons  that  conformto  the 
pol  i  cy. 

It  is  important  to  note  that  information  is  not  required  to  flow  into  or  out  of 
a  Block.  However,  a  completely  isolated  Block  would  not  be  useful. 

****************************************************************************** i 

s i  g  System  { 

resources:  set  Resource, 

bb:  BB, 

s r _ f  I  ow:  Subj  ect  -  resources  -  > Mo d e , 

MM:  Subject  ->  Resource  ->  Mode, 

--  This  used  in  this  model  for  modeling  reading  and  writing. 

RM:  resources  ->  Me  mo  r  y  _  Seg  me  n  t 

} 
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Every  Block  participates  in  the  System. 

We  start  with  an  empty  matrix  and  then  we  add  blocks 
Block  in  B I  oc  k .  (  (  b  b .  f  I  o  w)  .  Mod  e )  +  (  (  bb.  fl  ow) .  Mode)  .  Bl  ock 

s  r  _  f  I  o  w  is  non  empty 
s  o  me  s  r  flow 


/* 

&& 

--  This  constraint  is  only  to  create  interesting  models.  It  is  recommend  to 
--  comment  out  this  section  to  study  the  model  the  way  it  was  intended. 

--  A  completely  isolated  Block  is  not  useful  therefore: 

--  Every  block, 
all  bl:  blocks 

--  has  so  me  other  block, 
so  me  b  2 :  Block 

--  that  is  not  itself, 
d i  s  j  [ b 1 ,  b  2 ]  && 

( 

-  -  which  it  neither  f  I  o  ws  into, 
b2  in  bl.  f  I  ow  or 

-  -  nor  out  of . 
b2  in  f  I  ow.  bl 

) 

*1 

} 

/  * **************************************************************************** * 

We  are  interested  with  a  traditional  confidentiality  policy  between  the  Blocks 
that  prohibits  reading  up  or  writing  down.  The  separation  kernel  itself  only 
isolates  the  Blocks  and  regulates  the  flow  between  them,  but  is  devoid  of 
semantics  labeling  one  Block  greater  than  another. 

However,  we  can  define  a  predicate  that  will  require  the  Blocks  to  be 
partitioned  in  such  a  way  that  information  is  not  allowed  to  flow  circularly. 
That  is  if  information  leaves  BlockA,  there  is  no  transitive  closure  of  the 
flows  that  will  lead  back  to  BlockA.  It  is  important  to  note  that  any  two 
Blocks  are  not  required  to  be  related.  For  example,  Bl  ockA-  >BI  ockC, 

Bl  ockB-  >BI  ockC,  but  there  is  no  flow  between  BlockA  and  BlockB  and  no 
indication  if  one  is  greater  than  the  other.  Therefore  such  a  non-circular 
flow  of  information  is  technically  considered  a  partial  ordering  but  not  a 
total  ordering.  That  is,  not  all  the  items  in  the  set  are  comparable. 
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Mathematically  a  partial  ordering  (  PO)  is  defined  as  a  relation  over  a  set  that 
is  transitive  and  antisymmetric.  Antisymmetric  means  there  is  no  circularity 
in  the  relation.  Many  authors  extend  a  partial  ordering  to  include  reflexivity 
which  means  every  item  in  the  set  is  comparable  to  itselfs.  In  our  situation 
this  may  or  may  not  be  the  case.  We  include  reflexivity  in  PO  allowing  it  to 
be  commented  out  if  not  desired. 

Note:  A  lattice  is  a  partial  ordering  where  every  comparable  pair  of  items 
contain  both  a  least  upper  bound  (lub)  and  a  greatest  lower  bound  (gib),  which 
results  in  a  universal  upper  and  lower  bound  to  the  lattice. 

****************************************************************************** i 

pred  P  0  (  b  b :  Block-  >  B I  o  c  k )  { 

all  i  ,  j  ,  k :  (bb. Block  +  Block. bb) 

-  -  reflexive 

( 

i  -  >i  i  n  b b 

)  && 

-  -  a  n  t  i  s  y  mme  trie 

( 

( ( i  -  >j  in  b  b )  &&  ( j  -  >i  in  b  b )  )  =>  (  i  =j  ) 

)  && 

--  transitive 

( 

(  (  i  -  >j  in  bb)  &&  ( j  -  >k  in  bb))  =>  (  i  -  >k  in  bb) 


} 

/  * **************************************************************************** * 

Overtime  an  item  of  information  may  no  longer  be  sensitive  and  its  sensitivity 
may  need  to  be  downgraded.  To  do  so  requires  violating  the  partial  ordering. 
Therefore  the  notion  of  a  Trusted  Subject  is  introduced.  A  Trusted  Subject  is 
a  Subject  (ie.  process)  that  has  undergone  rigorous  analysis  and  is  trusted  not 
to  downgrade  information  other  than  the  information  it  is  intended  to 
downgrade. 

******************************************************************************  j 
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sig  Trusted  Subj  ect  extends  Subject  {} 


/  * **************************************************************************** * 

A  Trusted  Subject  is  allowed  to  violate  the  partial  ordering  but  it  is  not 
required  to  violate  the  partial  ordering.  Therefore,  there  may  be  flows  in  the 
System  that  are  the  result  of  the  Trusted  Subjects  and  violate  the  partial 
ordering.  The  problem  here  is  that  we  do  not  really  have  a  way  of  identifying 
which  Subject,  trusted  or  otherwise,  caused  a  flow  in  bb,  after  all  the 
matrices  are  intended  to  be  orthogonal.  However,  the  reverse  may  be  possible. 
We  can  identify  the  flows  in  s  r  _  f I  o  w  and  require  any  flow  that  upsets  the 
partial  ordering  in  bb  to  be  a  trusted  subject.  However,  this  also  requires  us 
to  identify  the  partial  ordering. 

****************************************************************************** i 

pr  ed  T P 0 (  s  y s :  Sy  s  t  em)  { 

let  Nontrusted_Subs_i  n_SR  =  domjsys.  sr_fl  ow]  -  Trusted_Subj  ect, 

NontrustedBI  ockFI  ow  =  {  bl,  b2:  Block  ,  m:  Mode  | 

( 

some  sub:  Nontrusted_Subs_i  n_SR,  r:  Resource 

( 

--  sub  is  a  non-trusted  subject  in  the  subject  part  of  s  r  _  f  I  o  w 
--  when  combined  with  some  resource  and 

--  and  the  mode  of  Nontrusted_BI  ock_FI  ow  is  also  in  s  r  _  f  I  o  w 
(sub  -  >  r  -  >  m)  in  sys.  srfl  ow  and 

--  and  the  corresponding  blocks  of  that  subject  and  resource 
--  comprises  the  blocks  of  Nontrusted_BI  ock_FI  ow 
bl  =  sub.master  and  b2  =  r.master 

) 

) 

} 

--  The  transitive  closure  of 

--  the  intersection  of  the  Nontrusted_BI  ock_FI  ow  and  bb.flow 
-  -  wi  t  h  the  Mode  r  emoved 
■■  should  be  a  partial  ordering 

P  0  [  (  NontrustedBI  ockFI  ow  &  sys.  bb.  f  I  ow)  .  Mode)  ] 

} 

/  * **************************************************************************** * 
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A  secure  system  is  a  system  that  is  a  trusted  partial  ordering  where  only  flows 
in  by  both  matrices  ( s  r  _  f  I  o  w  and  bb.flow)  are  allowed. 

****************************************************************************** i 


pred  Securef  sys:  System) 

{ 

T  P  0 [ sys]  && 

all  sub:  Subject,  res:  Resource,  mod:  Mode 

( 

(sub  -  >  res  ■>  mod)  in  sys.  MM 

=  > 


(sub  ->  res  ->  mod)  in  sys. srfl  ow  && 
mod  in  sys.  bb.  fl  ow[sub.  master][res.  master] 


} 

/  * **************************************************************************** * 

The  above  defines  a  secure  system  and  what  it  means  to  be  in  a  secure  state. 

In  the  strictest  sense  the  concept  of  transitioning  fromone  state  to  another 
does  not  exist  in  this  definition  because  the  system  is  static  and  either  the 
system  is  secure  or  it  isn't.  The  matrices  do  not  change  once  brought  into 
exi  st  ence. 

In  order  to  visualize  transitions  operation  we  create  a  Transition  signature 
that  includes  the  current  system  along  the  with  the  last  command  executed,  the 
corresponding  arguments,  and  the  last  error  message. 

This  model  represents  the  runtime  phase  of  the  system. 

******************************************************************************  j 

--  List  of  commands  in  the  preliminary  interface, 
abstract  s  i  g  Co  mma  n  d  { } 
one  sig  no_op_com, 
r  e  a  d  _  c  o  m, 
wr  i  t  e_ c  o  m 
extends  Command  {} 
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An  error  for  each  co mma n d 


abstract  s i  g  Error  {  } 
one  s i  g  n o _ e r  r , 
read_err, 
wr  i  t  e _  e  r  r 
extends  Error  {} 

s  i  g  Transition 

{ 

error_message:  Error, 

I  a  s  t  _  c  o  mma  n  d :  Co  mma  n  d , 
arguments:  set  u  n  i  v , 

s  ys :  System 

} 


/  * **************************************************************************** * 

We  begin  the  ordering  of  Transitions  (states)  with  a  secure  System  and  no  error 
messages  nor  commands  having  been  executed. 

Then  we  define  a  transition  as  having  unchanged  matrices  and  either  a  read  or 
a  write  having  occurred.  In  the  transition  the  security  of  the  new  System  is 
not  stated.  This  is  left  for  an  assertion  to  verify  that  no  transition  will 
lead  to  an  unsecured  System. 

****************************************************************************** i 

fact  i  ni  t_run_ti  me 

{ 

let  t  =  Seq:  :  run_ti  me_seq/fi  rst[ ] 

n  o  _  e  r  r  =  t.  errormessage  && 
no_op_com  =  t .  I  a s t  _ c o mma n d  && 
n  o  t .  a  r  g  u  me  n  t  s  && 

Secure[t.  sys] 

} 


fact  trans_run_ti  me 

{ 

--  This  is  for  mo  re  interesting  mo  dels 
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-  -  set_up_seq/  al  I  Exi  s  t  No  Du  pi  i  c  a  t  e  s  [  ]  && 

--  For  all  seqence  indices  except  the  first  one 

all  sqidx:  Seq:  :  run_ti  me_seq  /  I  nds[  ]  -  run_ti  me_seq/fi  rstl  dx[ ] 

{ 

let  t  =  run_ti  me_seq/Seq:  :  at[  run_ti  me_seq/prev[sqi  dx]  ], 
t 1  =  run_ti  me_seq/Seq:  :  at[sqi  dx] 

--  To  prevent  a  tranisition  that  is  the  same  command,  same  args, 
--  same  error  and  same  system  from  occuring  next  to  each  other 
-  -  di  sj  [ t 1  .  sys,  t .  sys]  && 

some  s:  System, 

■■  given  some  resource  and  subject  in  the  system 
res:  ( t .  s  y  s )  .  r  es  ou  r  c  es ,  sub:  (Subject  &  res), 

--  and  their  corresponding  memory_segments 
segR:  res.  (t.  sys.  RM),  segS:  sub.(t.sys.RM) 

{ 

--  either  a  read 

( 

( 

readjt.sys,  s,  res,  segR,  sub,  segS]  && 

Secure!  s] 

) 

=  >  ( 

t 1 .  sys  =  s  && 

t 1  .  I  a  s  t  _  c  o  mma  n  d  =  read_com  && 

t1  .  arguments  =  res  +  segR  + 

sub  +  s  eg  S  && 
t'.error_ message  =  n  o  _  e  r  r 

) 

else  ( 

t 1 .  sys  =  t .  sys  && 

t 1  .  I  a  s  t  _  c  o  mma  n  d  =  read_com  && 
t1  .  arguments  =  res  +  segR  + 

sub  +  s  eg  S  && 
t'.error_ message  =  read_err 
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or  a  write  occurred 


wri  te[t.  sys,  s,  res,  s  e  g  R ,  sub,  segS]  && 

Sec  u  r  e[ s  ] 

) 

=  >  ( 

t 1 .  sys  =  s  && 

t 1  .  I  a  s  t  _  c  o  mma  n  d  =  read_com  && 

t1  .  arguments  =  res  +  segR  + 

sub  +  s  eg  S  && 
t'.error_ message  =  n  o  _  e  r  r 

) 

else  ( 

t 1 .  sys  =  t .  sys  && 

t 1  .  I  a  s  t  _  c  o  mma  n  d  =  wri  tecom  && 
t1  .  arguments  =  res  +  segR  + 

sub  +  s  eg  S  && 
t'.error_  message  =  wri  te_err 


}  -  -  s  o  me 
}- -  a!  i 

} 

^  ***************************************************************************** * 

Memory  modificaiton  represented  in  the  read  and  write  commands. 

****************************************************************************** i 

pred  r  e  a  d  ( s  y  s :  System,  sys1:  System, 

res:  Resource,  segR:  Me  mo  r  y_  Seg  me  n  t , 
sub:  Subject,  segS:  Me  mo  ry_  Segment ) 

{ 

-  -  then  me  mo  r  y  mo  d  i  f  i  c  a  t  i  o  n  occurs 

sys'.RM  =  (  (  sys.  RM)  -  (  sub  -  >segS)  )  +  (  sub-  >segR)  && 

sys1.  bb.  flow  =  sys.  b  b .  flow  && 
sys' .  sr_fl  ow  =  sys.  sr_fl  ow  && 
s  y  s 1  .  MM  =  s  y  s .  MM 

} 
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pred  wr  i  t  e  ( s  y  s :  System,  s  y  s 1  :  System, 

res:  Resource,  s  e  g  R :  MemorySegment , 
sub:  Subject,  segS:  Memor  y_  Segment ) 

{ 

-  -  then  me  mo  r  y  modification  occurs 

sys'.RM  =  (  ( sys.  RM)  -  ( res  -  >segR)  )  +  (  res-  >s  e  g  S )  && 

sys'.bb.flow  =  sys. bb. flow  && 
sys1  .  sr  fl  ow  =  sys.  sr_fl  ow  && 
s  y  s 1 .  MM  =  s  y  s .  MM 


pred  show  ()  {} 
run  show 


--  no  transitions  outside  of  the  sequence 
fact  every_t  ransi  ti  o n _ i  n_sequence 
{ 

Transition  in  run_time_seq/Seq::elems[] 

} 

--  Without  this  constraint  sequences  are  created  different  transitions 
fact  exact  I  y_one_sequence 
{ 

one  Seq 

} 

assert  SecureTrans  {  all  t:  Transition  |  Se c u r e [ t .  s y s  ]  } 
check  SecureTrans  for  3 
check  SecureTrans  for  4 
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APPENDIX  D :  MORPHISM  EXAMPLE  IN  ALLOY 


mo  d  u  I  e  mo  r  p  h  i  s  m_  d  e  mo 

/  * **************************************************************************** * 

Spec  ware  4.1  Tutorial 
Chapter  1.3.4  Morphisms  p a g 3  7 

As  another,  less  trivial  example,  consider  a  spec  for  natural  numbers  that  also 
includes  an  op  plus  and  an  op  times,  both  of  type  Nat  *  Nat  ->  Nat.  (The 
construct  builds  the  cartesian  product  of  two  types:  in  a  model,  A  *  B 
denotes  the  cartesian  product  of  the  set  denoted  by  A  and  the  set  denoted  by 


B.  ) 

The 

spec  a  1 

so  cont  ai 

ns  axi 

o  ms 

that  define 

plus  and  t  i  me  s 

t  0 

be 

a d d i  t i  on 

a  n  d 

mu  1  t 

i  pi  i  cat 

ion.  Now, 

cons  i 

der 

another  spec 

consi  st i  ng  of 

a 

type 

X,  an  op  f 

of 

type 

X  *  X  - 

>  X,  and 

an  axi 

o  m 

stating  that 

fisc  ommut  at  i 

ve : 

f  a  (  x ,  y )  f  (  x ,  y )  =  f(y,x) 

****************************************************************************** i 


/  * **************************************************************************** * 

Source  Speci  f i  cat i  on 

/  * **************************************************************************** / 

one  s i  g  Nat  { 

r  el  :  Nat  -  > N a t  -  > N a t 

} 

pr  ed  op  (  nl,  n 2 ,  n3:  Nat )  { 

(  n  1  -  >n  2  -  >n  3 )  in  (  Na  t .  r  e  I  ) 

} 

fact  co  mmu  native  { 
all  nl,  n  2 ,  n3:  Nat 

o p [  n  1 ,  n 2 ,  n 3 ]  <  =  >  o p [  n 2 ,  nl,  n 3 ] 

} 


/  * **************************************************************************** * 
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Target  Specification 


/  * **************************************************************************** / 

sig  X  extends  Nat  {} 

pred  o p x ( x  1 ,  x 2 ,  x3:  X)  { 
o  p  [  x  1 ,  x  2 ,  x  3  ] 

--  further  operation  definition  would  go  here 

} 

assert  mo  r  p  h  i  s  m{ 
all  x  1,  x  2 ,  x3:  X  | 

o  p  x [ x 1 ,  x  2 ,  x  3 ]  <  =  >  o  p  x [ x  2 ,  x  1 ,  x  3  ] 

} 

check  mo  r  p  h  i  s  m 

pred  show()  { } 
run  show 
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